System, method, and device of authenticated encryption of messages

ABSTRACT

System, device, and method of authenticated encryption of messages. A message intended for authenticated encryption is stored; and a secret authentication key and a secret encryption key are stored. A key-stream set of blocks is generated, each block including pseudo-random bits. The aggregate length of the key-stream is equal to or greater than the message-length of the message. Each block of the key-stream is generated by a deterministic pseudo-random number generator function that is instantiated with the secret encryption key. The key-stream is generated on a block-by-block basis, until the key-stream reaches in aggregate the message-length of the message. Each block of bits of the message is encrypted, on a per-block basis, with a corresponding block from the key-stream. Authentication is performed on the result of the encrypting operation, or on the message, by applying a keyed cryptographic checksum function that ascertains integrity and that utilizes the secret authentication key.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority and benefit from U.S. provisional patent application No. 62/006,274, titled “Side Channel Tolerant Provisioning”, filed on Jun. 2, 2014, which is hereby incorporated by reference in its entirety. Additionally, this application is a Continuation-in-Part (CIP) of U.S. patent application Ser. No. 14/187,275, filed on Feb. 23, 2014; which in turn was a Continuation-in-Part (CIP) of U.S. patent application Ser. No. 12/947,381, filed on Nov. 16, 2010, now U.S. Pat. No. 8,687,813; which in turn claimed priority and benefit from U.S. provisional patent application No. 61/272,890, filed on Nov. 16, 2009; all of which are hereby incorporated by reference in their entirety.

FIELD

The present invention relates to the field of security solutions for electronic devices.

BACKGROUND

Key Provisioning is a problem common to many cryptographic modules. Whenever a cryptographic device is designed to perform operations using internally-stored key material, this key material needs to be available to the cryptographic device.

For most key material, provisioning may be performed by means defined at the application level. Most applications may support methods to securely communicate keys to the participants of their security protocols. Provisioning methods specified by applications may usually rely on pre-existing key material, which may be used to secure a subsequent provisioning process. Other applications may perform provisioning without pre-existing key material, for example, if their threat models allow that.

SUMMARY

The present invention may comprise, for example, systems, devices, and methods of provisioning cryptographic materials, or any other data or data items, to one or more electronic devices. The provisioned cryptographic materials may comprise, for example, security key materials, encryption keys, decryption keys, public keys, private keys, passwords, pass-phrases, Personal Identification Number (PIN), or other data intended to be securely provisioned.

For example, a method of cryptographic material provisioning (CMP) may comprise: (a) generating a delegation message at a first provisioning server, wherein the delegation message indicates provisioning rights that are delegated by the first provisioning server to a second provisioning server with regard to subsequent provisioning of cryptographic assets to an electronic device, wherein generating the delegation message comprises at least one of: (A) inserting into the delegation message an association key unknown to the first provisioning server, encrypted using a public key of said electronic device, wherein said public key of said electronic device is usable to encrypt data for subsequent decrypting by said electronic device using said private encryption key of said electronic device; (B) inserting into the delegation message a public key of the second provisioning server; enabling the electronic device to locally generate said association key unknown to the first provisioning server; wherein the association key is retrievable by the second provisioning server based on the public key of the second provisioning server; (b) delivering the delegation message from the first provisioning server to the electronic device; (c) at the second provisioning server, and based on said delegation message, provisioning one or more cryptographic assets to the electronic device, using said association key.

In some embodiments, the first provisioning server, by listening to all communications among the first provisioning server, the second provisioning server, the electronic device, and an authorization server, cannot decipher the contents of one or more cryptographic assets that are provisioned by the second provisioning server to the electronic device, even though said first provisioning server delegated to said second provisioning server one or more provisioning rights to subsequently provision one or more of said cryptographic assets.

In some embodiments, the first provisioning server, which introduced the second provisioning server to the electronic device for purposes of subsequent provisioning of cryptographic assets, cannot decipher data exchanged between the second provisioning server and the electronic device, even though the second provisioning server and the electronic device did not have any shared secrets and did not have any cryptographic key data usable for secure communication between the second provisioning server and the electronic device prior to said introduction by said first provisioning server.

In some embodiments, the method may comprise: delegating from the first provisioning sever to the second provisioning server, a right to securely send a cryptographic asset from the second provisioning server to the electronic device, wherein the first provisioning server cannot decipher any cryptographic asset that is sent from the second provisioning server to the electronic device.

In some embodiments, generating the delegation message comprises: inserting into the delegation message a public key of the second provisioning server, to enable execution of an identification protocol for subsequent personalized provisioning of a cryptographic asset to said electronic device.

In some embodiments, generating the delegation message comprises: inserting into the delegation message an association key to be used with the second provisioning server, to enable subsequent execution of provisioning of a cryptographic asset to one or more electronic devices using said association key.

In some embodiments, delivering the delegation message to the electronic device is performed via a one-pass one-way communication from the first provisioning server to said electronic device.

In some embodiments, the method may comprise, prior to performing step (a): securely delivering from the second provisioning server to the first provisioning server, via a secure communication channel, (A) a public encryption key of the second provisioning server, and (B) a class-wide association key encrypted with a key that allows the association key to be decrypted by said electronic device.

In some embodiments, the method may comprise: provisioning from the first provisioning server to the electronic device, via a one-pass one-way provisioning protocol, at least: (i) the public encryption key of the second provisioning server, (ii) the server certificate of the second provisioning server, digitally signed by an authorization server; (iii) an indication of which cryptographic assets the second provisioning server is authorized to subsequently provision to the electronic device.

In some embodiments, generating the delegation message comprises: inserting into the delegation message one or more flags indicating to the electronic device whether the second provisioning server is authorized to provision: (X) only personalized cryptographic assets, or (Y) only class-wide cryptographic assets for a class of multiple electronic device, or (Z) both personalized and class-wide cryptographic assets.

In some embodiments, the method may comprise: prior to provisioning a particular cryptographic asset from the second provisioning server to the electronic device, performing: acquiring by the second provisioning server an authorization ticket, from an authorization server, indicating that the second provisioning server is authorized to provision the particular cryptographic asset to said electronic device.

In some embodiments, said acquiring of the authorization ticket is triggered by a flag, indicating that authorization is required for each provisioning event performed by the second provisioning server, the flag located in a server certificate issued by said authorization server to the second provisioning server.

In some embodiments, the acquiring comprises: at the second provisioning server, contacting the authorization server to present to the authorization server (A) a server certificate of the second provisioning server, and (B) a hash of the particular cryptographic asset intended to be provisioned by the second provisioning server to the electronic device.

In some embodiments, the acquiring further comprises: receiving at the second provisioning server, from said authorization server, said authorization ticket which comprises a digital signature by the authorization server on the hash of the particular cryptographic asset intended to be provisioned by the second provisioning server to the electronic device; wherein said digital signature enables said electronic device to verify by the electronic device prior to storing said particular cryptographic asset.

In some embodiments, provisioning the cryptographic asset to the electronic device is performed via a one-pass one-way communication from the second provisioning server to said electronic device.

In some embodiments, a device or apparatus or system for cryptographic material provisioning (CMP) may comprise: a first provisioning server to generate a delegation message, wherein the delegation message indicates provisioning rights that are delegated by the first provisioning server to a second provisioning server with regard to subsequent provisioning of cryptographic assets to an electronic device, wherein the first provisioning server is to generate the delegation message by performing at least one of: (A) inserting into the delegation message an association key unknown to the first provisioning server, encrypted using a public key of said electronic device, wherein said public key of said electronic device is usable to encrypt data for subsequent decrypting by said electronic device using said private encryption key of said electronic device; (B) inserting into the delegation message a public key of the second provisioning server; enabling the electronic device to locally generate said association key unknown to the first provisioning server; wherein the association key is retrievable by the second provisioning server based on the public key of the second provisioning server; wherein the first provisioning server is to cause delivery of the delegation message from the first provisioning server to the electronic device; wherein the second provisioning server is to provision, and based on said delegation message, one or more cryptographic assets to the electronic device, using said association key.

The present invention may provide other and/or additional benefits or advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

For simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity of presentation. Furthermore, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. The figures are listed below.

FIG. 1 is a schematic block diagram illustration of a provisioning message preamble generator, which may be used by a target device root owner, in accordance with some demonstrative embodiments of the present invention;

FIG. 2 is a schematic block diagram illustration of a provisioning message generator, which may be used by a first delegate, in accordance with some demonstrative embodiments of the present invention;

FIG. 3 is a schematic block diagram illustration of a provisioning message preamble generator, which may be used by a first delegate to generate a message second portion for a preamble useable by a second delegate, in accordance with some demonstrative embodiments of the present invention;

FIG. 4 is a schematic block diagram illustration of a provisioning message generator, which may be used by a second delegate, in accordance with some demonstrative embodiments of the present invention;

FIG. 5 is a schematic block diagram illustration of a target device comprising a cryptographic material provisioning module able to receive a provisioning message, in accordance with some demonstrative embodiments of the present invention;

FIG. 6 is a schematic block diagram illustration of an electronic device, in accordance with some demonstrative embodiments of the present invention; and

FIGS. 7A-7E are schematic block-diagram illustrations of a system and its components, in accordance with some demonstrative embodiments of the present invention.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of some embodiments. However, it will be understood by persons of ordinary skill in the art that some embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, units and/or circuits have not been described in detail so as not to obscure the discussion.

Applicants have realized that in some implementations, the entity that installs key material in an electronic device (“the “Installer”), while operating on behalf of the owner of the device asset (the “Owner”), may not necessarily be entirely trusted by the Owner. The provisioning process, if performed without measures against compromise by the Installer, may require extremely high levels of trust on behalf of the Owner. In some cases, such trust may not be granted, leading to the need to devise a system that protects the provisioning process against compromise also by the Installer.

Applicants have further realized that another source for complexity stems from the possible existence of Sub-owners. A Sub-owner may be an entity which is not the owner of the device asset, but which owns some of the key material to be placed in it. Each Sub-owner may have its own one or more Installer(s). The same trust issue between the Owner and its Installer may similarly exist for each Sub-owner and any of its respective Installer(s). Additionally, partial distrust may exist between the Owner and its Sub-owners. The Owner may trust the Sub-owner to provide its devices with key material, but the Owner may not trust the Sub-owner to overwrite other key material, such as that installed by the Owner or by any other Sub-owner. In many cases, the Owner may not accept the ability of one of its Sub-owners to obtain key material provisioned by another Sub-owner. In other cases, the sub-owner may trust the owner with its secrets.

Applicants have realized that the problem of key provisioning may be stated as the need to: (a) allow Owner to allow Installer (one or more) to provide the device with key material on behalf of the Owner, without exposing the key material to the Installer that performs the physical provisioning operation; (b) allow a similar model for more than one Sub-owner, each having associated with it one or more Installers; (c) prevent any Sub-owner from obtaining key material provisioned by another Sub-owner; (d) allow Owner to control what key material each Sub-owner provisions through its Installers, while not having possession of the provisioned material itself. The client-side of an implemented solution for the problem may fit within the capabilities of an embedded chip-set, and may be adapted to be performed in short times, e.g., during fabrication.

The present invention includes methods, circuits, devices and systems for provisioning of cryptographic material (e.g., cryptographic keys or data to one or more electronic devices. According to embodiments, a provisioning message preamble for a specific target device and/or for a specific group of devices (e.g., specific make and model of cell-phones) may be generated and provided to a party intending to install or otherwise use a functional cryptographic key (i.e., cryptographic material) on the target device. The provisioning message preamble, operating in concert with a Cryptographic Material Provisioning Module (CMP), also referred to as “Key Provisioning System”, on the target device, may provide for: (1) a multilevel delegation hierarchy/structure for provisioning cryptographic keys to the target device, such that the native (root) key owner of the device (the part with the highest level of unrestricted rights) may delegate complete or partial key provisioning rights to one or more other parties, and some or all of the other parties may further delegate some or all of their respective rights to other parties along a hierarchical chain whose length and/or count has no predefined limit, (2) partial delegation functionality (e.g., based on key types) such that any member in a provisioning rights delegation hierarchy may define which key provisioning rights its delegate or delegates receive, including the right to further delegate or not, as long as those rights do not exceed the rights of the delegating party.

The provisioning message preamble may be constructed of one or more message portions or segments, and the first portion or segment may be encrypted and/or signed using the target device's native/root key. The first portion of the preamble may include first cryptographic material and a permissions data vector, which vector may include one or more usage restrictions including: (1) what type of keys may be provisioned to the target device by the user of the preamble (e.g., first delegate), and (2) an indication of whether the user of the preamble may convey key provisioning rights or sub-rights further down a rights delegation hierarchy or chain.

In some embodiments, a provisioning message may include a preamble and a payload, such that the preamble may be constructed and utilized in a particular manner in order to indicate or facilitate authorized provisioning and/or delegation of provisioning authorization. In other embodiments, preamble(s) need not be used; and instead, messages may be used in conjunction with suitable protocols (e.g., identification protocol, provisioning protocol, querying protocol) in order to enable provisioning, delegation, and other functionalities as described herein.

The provisioning message preamble (i.e., first portion of the provisioning message) may be configured such that a second provisioning message portion, including cryptographic material (e.g., functional key or keys which are the subject of provisioning), may be appended to the preamble (e.g., by the first delegate) to generate a complete first provisioning message. The second portion of the provisioning message may be encrypted and/or signed by the first cryptographic material (e.g., a first cryptographic key provided by or otherwise known by the first delegate) within the preamble. According to embodiments, a CMP on a target device receiving the complete provisioning message may process the preamble by: (1) decrypting the preamble using the devices native/root key, (2) extracting from the preamble the first cryptographic material and the permissions data vector, (3) decrypting the second portion of the message using the extracted first cryptographic material, (4) extracting a functional key or keys (second cryptographic material) within the second portion, (5) checking the extracted functional key or keys (second cryptographic material) against usage permissions defined in the permissions data vector within the preamble to determine whether the extracted key or keys are of a type permitted for provisioning by the permissions data vector, and (6) provisioning the keys to the target device (installing, storing or otherwise using) if the extracted key type(s) are permitted and the preamble is valid.

According to further embodiments, the second provisioning message portion may include second cryptographic material which is not a functional key (i.e., a key which is the subject of provisioning to the target device), but rather cryptographic data (e.g., key, link to key, etc.) for decrypting and/or authenticating a third portion (e.g., provided by a second delegate) of the provisioning message, which third portion may be appended (e.g., by the second key provisioning delegate) behind the second portion. According to this embodiment, the second portion may also include a second permissions data vector indicating usage limitations of any cryptographic material (e.g., third cryptographic material or key) to be extracted from the third message portion. In this event, when the third portion includes a functional key, the combined first and second portions may collectively be considered the provisioning message preamble, and the third message portion including the functional key (e.g., provisioned by the second delegate) to be the subject of provisioning on the target device may be considered the message body. According to embodiments where the first portion of the preamble is appended by a second portion which also includes cryptographic material and/or a second permissions data vector, the combined cryptographic material and permission data vectors of the first and second portions may be termed a “delegation structure”, which delegation structure provides the means (cryptographic material for decrypting) and defines allowable usage (types of keys allowed for provisioning on the target device) for one or more functional cryptographic keys to be provisioned by the second delegate to the target device.

Likewise, a third provisioning message portion may be added by a second delegate with cryptographic material (e.g., key, link to a key, or the like) required for decrypting and/or authenticating a fourth portion of the provisioning message, which fourth portion may be appended (e.g., by a third delegate) behind the third portion. If the fourth portion includes a functional key, the first through third portions of the message may be considered the preamble including the delegation structure required to access and process the functional key of the fourth portion.

It should be understood that such a chain of provisioning message portions, where cryptographic material in one portion may be used to decrypt/authenticate and extract data from the next, has no inherent limitation in count. By providing for portions of a provisioning message to be appended to one another according to the methodology described, a length or size of a provisioning rights delegation chain or hierarchy (i.e., delegation structure) may be indefinite, with each provisioning rights delegate being able to provide sub-rights to a sub-delegate, as long as none of the delegated rights exceed or contradict any usage restrictions (e.g., which types of keys may be installed) found in any of the permissions data vectors of any preceding message portions.

Since data processing at the target device of a provisioning message according to embodiments of the present invention is substantially sequential, according to some embodiments the data processing and/or data processor (e.g., CMP) may be a state-machine. Since data processing at the target device of a provisioning message according to embodiments of the present invention is substantially sequential, according to some embodiments the data processing and/or data processor (e.g., CMP) may not require access to a non-constant amount of memory for storage of cryptographic material within the provisioning message to support an infinite number of delegation levels.

A “Root Key”, denoted R, may be the one key in each device that is used as the root trust anchor. This is the first key that may be used when decrypting and authenticating a Provisioning Message. It is the only key material that is assumed to pre-exist in all provisioned devices. It may be facilitated by the means described below. It is noted that in some embodiments, the Root Key (R) may optionally have similar or identical functionality to the ICV Root of Trust that is further described herein, or vice versa

The Root Key may either be a single key used in an entire lot (or batch) of devices, or it may be device-specific. Having the Root Key be device-specific may increase security, but may be more difficult to manage and may sometimes be technically infeasible.

The Root Key stored by the device may be made available to the provisioning process requiring it in one of three ways: (a) it may be recalled from Internal Protected Storage, such as EEPROM, or other non-volatile memory, where it was stored as part of a root key provisioning; (b) it may be made available as a hard-coded part of the logic implemented in the device or chip; (c) it may be derived from one or more Root Key Components. The length of the Root Key field (and the key itself) may be 128 bits, 256 bits, 512 bits, 1,024 bits, 2,048 bits, 4,096 bits, or any other suitable length.

Functional Keys may be the subject of provisioning. These may be the pieces of information (e.g., cryptographic material) that may be delivered to the device as part of the provisioning process, and which may be consumed on the device by other processes after the provisioning process concludes. A Functional Key, denoted herein as k, may not necessarily be a cryptographic key. This “functional key” may be an opaque field which may never be interpreted by the CMP. Therefore, it may be a wrapper for any data within reasonable length requirements. Each Functional Key may be a field of a larger structure, which is the Key Structure. The Key Structure may be the object maintained by the CMP which may store the Functional Key and associated metadata.

In a demonstrative implementations, the data which consists of the Key Structure may include: (a) “Key Value”, which may be the Functional Key, k; (b) “Key ID”, which may be an identifier of the key or structure, which is typically unique; (c) “Key Type”, which may be a string representing the Key Type of the Functional Key k; (d) “Key Slot”, which may be a string representing the Key Slot of k, within the Key Type.

Each Functional Key that is processed (e.g., received and stored) by the Key Provisioning System, is associated with a Key Type. The key type may be a non-unique string representing the usage, purpose, or application of the key. This property may be provided to Sub-owners as means for control delegation. The Key Type may also be used as part of the key metadata which is read by the application that uses the key, e.g., to determine the usage of the key, or to allow an application to detect its own keys in a repository that contains keys of several applications.

The namespace of a Key Type field may be maintained by an Owner, and possibly by its one or more Sub-owners. In some implementations, the value of Key Type may be a string, which may be processed only by functions of sub-string concatenation and comparison.

As a demonstrative example for the possible uses of the Key Type field, an Owner (and possibly one or more of its respective Sub-owners) may use the following values for Key Type fields: (a) System/Firmware Update/Verification; (b) System/AntiTheft/Attestation; (c) Apps/PaymentApp/Encrypt; (d) Apps/PaymentApp/Sign; (e) Apps/DRM/Scheme1/GroupPrivate; (f) Apps/DRM/Scheme1/ServerParameters.

A “Key Slot” may be a field which may be provided for distinguishing between keys that have the same Key Type. When more than one key of a given Key Type is provisioned by a Key Provisioning System, each of those keys may have a different Key Slot value in its Key Slot field. The Key Slot values may repeat among keys of different Key Types. The value in a Key Slot may be an integer counter. The value in a Key Slot may be a short string having any suitable value and which may be treated as an opaque value which may be used for comparison purposes.

The combination of values in the Key Type and Key Slot fields may be unique on a target device. However, there may be no requirement for the Key ID field to be unique. It is likely to be unique due to its nature and name, but its uniqueness is not a requirement of the Key Provisioning System. For the Key Provisioning System, the value in Key ID may be an opaque string which is stored so it may be used by client applications.

A Provisioning Structure” may be a data object that is sent in the Provisioning Message. A single Provisioning Message may contain one or more instances of a Provisioning Structure. The client-side of the Key Provisioning System may accept a Provisioning Message from an Installer, and may act based on each Provisioning Structure the message may contain.

Each Provisioning Structure may contain, or may refer to, a single Functional Key that may be processed by the Key Provisioning System. The Provisioning Structure object may consist of two parts: a Preamble and a Body. The Preamble may contain zero or more instances of a Delegation Structure; and the Body may contain the actual command and data necessary for a key provisioning operation. The Provisioning Structure may be regarded as consisting of zero or more instances of Delegation Structures, followed by a Body structure.

The “Delegation Structure” object may be an object designed to communicate from an Owner or a Sub-owner to the Key Provisioning System on the device, its approval to have a target Sub-owner issue the command which appears in the Body object of that Provisioning Structure. The target Sub-owner is not identified in the structure, because there is no naming convention and enforcement for Sub-owners. Rather, the target Sub-owner is referenced by a key it possesses.

The key that the target Sub-owner uses is denoted as P_(i), with i being an indicator of the position of that Delegation Structure object in the series of such structures in the Provisioning Structure. For example, P₁ is the key that is held by the Sub-owner who was delegated with authority to provision keys by Owner, who is holding on to R; while P₂ is the key that is held by the Sub-owner who was delegated with authority to provision keys by the Sub-owner that holds P₁ above, and so forth.

The Preamble structure of the Provisioning Structure object may contain an ordered set of Delegation Structure objects, introducing P₁ . . . P_(n) in order. While a limit on n may be specified by particular implementations of the present invention, the design allows n to be arbitrarily large, e.g., by not linking its value to required system resources other than processing time. For example, a Provisioning Structure causing the insertion of a certain key may start with a Delegation Structure from Owner (holding R) to a Sub-owner P₁, allowing it to provision the key, followed by a Delegation Structure created by the Sub-owner P₁ to another Sub-owner holding on to P₂, allowing this one to provision that key, followed by the actual key insertion command authorized by the Sub-owner P₂.

Restricting Delegation by Key Types: Each delegation may be bound to a group of allowed Key Types. Such groups may be described using a Key Type Prefix (Permissions Data Vector). A delegation may apply to one such prefix. Delegation issued for a Key Type Prefix “a” may imply that the target Sub-owner of the delegation controls only the part of the Key Type namespace starting with “a”. The owner of R, who is Owner, may control the entire namespace of Key Type.

Each Sub-owner may be able to only delegate with a Key Type Prefix that is a continuation of the Key Type Prefix by which it was itself delegated. For example, a Sub-owner holding on to P₂ and who was delegated (by the Sub-owner P₁) with the Key Type Prefix “Apps/DRM/Scheme1”, can only delegate to the Sub-owner holding on to P₃ based on prefixes such as “Apps/DRM/Scheme1/XYTelecom”, or even “Apps/DRM/Scheme1” itself, but not, for example, “Apps/MPayment”.

The Delegation Structure object may comprise the following fields:

Target Key: a 128-bit (or other) key that is held by the target Sub-owner. This field contains P_(i) in an encrypted form.

Allowed Type Segment: The Key Type Prefix of the Key Types that are allowed to be processed by the Sub-owner P_(i).

Delegation Auth: A MAC on the above fields, indicating the approval of the owner of P_(i-1) to delegate the permission to operate on keys of the above Key Type Prefix, to the Sub-owner who is the owner of P_(i).

The Target Key may contain P_(i) in an encrypted form. Encryption may be done by AES ECB, with a key that derives from P_(i-1) (or R, if i=1). The encryption key, K_(E), may be computed in accordance to any known method including those described herein, with a CMAC PRF in accordance to any known methods, including those described below:

$\begin{matrix} {L = {E\left( {P_{i - 1},0^{b}} \right)}} & (1) \\ {K_{1} = \left\{ \begin{matrix} {L{1}} & {{{MSB}_{1}(L)} = 0} \\ \left( {{L\left. 1 \right)} \oplus {0^{120}10000111}} \right. & {{{MSB}_{1}(L)} \neq 0} \end{matrix} \right.} & (2) \\ {T = {E\left( {P_{i - 1},{K_{1} \oplus \left( {1^{1}{{PROVDENC}}0 \times 00{0^{47}}10^{7}} \right)}} \right)}} & (3) \\ {K_{E} = T} & (4) \end{matrix}$

L may be an encrypted zero block using the effective key, P_(i-1).

K₁ may be a sub-key in accordance with any known method and/or those described herein. The method may be built so the encrypted block is exactly 128 bits, so that K₂ need not be calculated at all. The tag T, which is the KDF output, may consist of ECB encryption of a “1” bit (indicating rolling block number), a unique constant Label used by this specification for encryption keys, a 47-bit zero string which serves formally as a Context (constant, to achieve key persistence), and informally to pad the structure, and a binary representation of 128, which may be the required key length.

The Target Key field may then be computed as the AES ECB encryption of P_(i) with the encryption key deriving from P_(i-1), as follows: T ARGET K EY =E(K _(E) ,P _(i))

The value of Allowed Type Segment may be the Key Type Prefix that the Delegation Structure object applies to. The Allowed Type Segment may always be appended in its entirety to the Allowed Key Type derived when processing the earlier Delegation Structure object in the chain, with the Delimiter following it. For example, if the preceding Delegation Structure object caused the current Allowed Type to be —System/Apps—, and the value in Allowed Type Segment is “DRM”, then the resulting Allowed Type is —System/Apps/DRM—. The Delimiter, ‘/’, is implicitly appended after every insertion of an Allowed Type Segment value. Notwithstanding, this symbol may be allowed as part of the Allowed Type Segment.

The value of Delegation Auth may be a CBC-MAC computed over P_(i) and the Allowed Type Segment. The CBC-MAC may be computed using a key that derives from P_(i-1) (or R, if i=1). The MAC key, K_(l) may be computed in accordance with any known methods and those described herein with a CMAC PRF in accordance with:

$\begin{matrix} {L = {E\left( {P_{i - 1},0^{b}} \right)}} & (5) \\ {K_{1} = \left\{ \begin{matrix} {L{1}} & {{{MSB}_{1}(L)} = 0} \\ \left( {{L\left. 1 \right)} \oplus {0^{120}10000111}} \right. & {{{MSB}_{1}(L)} \neq 0} \end{matrix} \right.} & (6) \\ {T = {E\left( {P_{i - 1},{K_{1} \oplus \left( {1^{1}{{PROVDMAC}}0 \times 00{0^{47}}10^{7}} \right)}} \right)}} & (7) \\ {K_{I} = T} & (8) \end{matrix}$

Reference is also made to earlier explanations about the parameters being used.

The value of Delegation Auth may be computed as follows: Delegation Auth=CMAC(K _(l);(P _(i)∥Allowed Type Segment);128)

The Body object of the Provisioning Structure contains the provisioning payload. The payload is a command that carries out one of the following operations:

-   -   ADD Adds a key     -   DEL Deletes a key     -   ENU Enumerates (i.e., lists) the keys already stored

This Body object may comprise six fields:

-   -   COMMAND The command, represented by at least three bits, with         five remaining combinations reserved for future use.     -   KEY TYPE The Key Type of the key to be added or removed, or a         null value, for the enumeration command.     -   KEY SLOT The Key Slot of the key to be added or removed, or a         null value, for the enumeration command.     -   KEY VALUE The actual key to be added, or a null value for         commands that are not ‘ADD’. If not null, the contents of this         field are encrypted.     -   KEY ID The ID of the key to be added or removed, or a null value         for the enumeration command.     -   PAYLOAD AUTH A MAC on all the above fields.

The Key Value field may be the only field of which content is encrypted. Encryption may be done using AES CCM, or any other approved mode, with a key that derives from P_(i) (or R, if there are no Delegation Structure objects in that Provisioning Structure). P_(i) may be the key that was introduced by the last Delegation Structure object preceding the Body object. The encryption key, K_(E), may be computed in accordance with any known method with a CMAC PRF in accordance with:

$\begin{matrix} {L = {E\left( {P_{i - 1},0^{b}} \right)}} & (9) \\ {K_{1} = \left\{ \begin{matrix} {L{1}} & {{{MSB}_{1}(L)} = 0} \\ \left( {{L\left. 1 \right)} \oplus {0^{120}10000111}} \right. & {{{MSB}_{1}(L)} \neq 0} \end{matrix} \right.} & (10) \\ {T = {E\left( {P_{i},{K_{1} \oplus \left( {1^{1}{{PROVPENC}}0 \times 00{0^{47}}10^{7}} \right)}} \right)}} & (11) \\ {K_{E} = T} & (12) \end{matrix}$

The Key Value field may then be computed as the AES CCM encryption of the key to be provisioned, k, with the encryption key deriving from P_(i), as follows: K EY V ALUE =E(K _(E) ,k)

The value of Payload Auth is a CBC-MAC computed over all other fields of the Body structure. The CBC-MAC may be computed using a key that derives from P_(i) (or R, if i=1). The MAC key, K_(l), is computed in accordance with known methods with a CMAC PRF in accordance with:

$\begin{matrix} {L = {E\left( {P_{i},0^{b}} \right)}} & (13) \\ {K_{1} = \left\{ \begin{matrix} {L{1}} & {{{MSB}_{1}(L)} = 0} \\ \left( {{L\left. 1 \right)} \oplus {0^{120}10000111}} \right. & {{{MSB}_{1}(L)} \neq 0} \end{matrix} \right.} & (14) \\ {T = {E\left( {P_{i},{K_{1} \oplus \left( {1^{1}{{PROVPMAC}}0 \times 00{0^{47}}10^{7}} \right)}} \right)}} & (15) \\ {K_{I} = T} & (16) \end{matrix}$

Refer to earlier explanations about the parameters used.

The value of Payload Auth may be computed as follows: Delegation Auth=CMAC(K _(l);(Command∥Key Type∥Key Value∥Key ID);128)

The following functions may be performed by a Key Provisioning System according to some embodiments.

Root Key Provisioning is the operation in which the value of R is entered into the device. Single Value Insertion—Provided that there are no pre-existing secrets on the device which can be employed for secure provisioning of R, it can only be inserted into the device by means that allow only for its setting, never for its unrestricted retrieval. Such means can be programmed as part of the Key Provisioning System, as long as the storage used to keep R is such that, while being run-time programmable, is not readable by logic which is not part of the Key Provisioning System.

In the case of a global R value, this value can be included as part of the RTL (Register Transfer Level) description provided to the chip manufacturer. Obfuscation techniques may be used to disguise the value of R so that it is not readily evident to whoever views the RTL description.

Two exemplary options for inserting the value of R: (a) using a write-only mechanism as part of the Key Provisioning System, along with exclusive-access storage; (b) using a hard-coded value of R for a group of devices.

The value of R may be random, deriving from an approved PRNG that was fed by an approved (given the existence of one) RNG.

Multiple Shares Insertion: instead of inserting a single R value, multiple Root Key Components may be inserted. Each Root Key Component value is inserted as if it was the single value of R, as detailed above. That is, each Root Key Component can be included in the RTL or received into the device (e.g., using a write-only mechanism). R will be computed from these components (a.k.a., “key shares”) as a combination of them all.

Owner may have knowledge of all Root Key Components, to be able to exercise its right as the root provisioning entity. However, it does not need to actually store all components. It is enough for Owner may compute the value of R that all components convey together and store this value.

The provision of the Root Key, R, as several Root Key Component values rather than as a single Root Key value has no implication on the perception of R as a root of trust for provisioning, and all operations using R have the same security model. The only implication of provisioning R as a set of components is on the trust it requires of the entities provisioning (or otherwise having access to) these components. In accordance with the Trivial Secret Sharing Scheme being used in the Key Provisioning System, when allowing each one of n entities to provision a single Root Key Component each, none of these entities can determine R with better than pure guessing probability on the entire key space or R. This assertion also applies to any group of i colluding entities, just as long as i<n.

The value of each Root Key Component R_(i) shall be random, deriving from an approved PRNG that was fed by an approved (given the existence of one) RNG. No waivers or exemptions apply in spite of the fact this single value cannot itself recover, or assist the recovery of, the Root Key.

Root Key Derivation: if the value of the Root Key was provided as a single Root Key value, then its derivation is by reading it.

If the value of R was not provisioned explicitly, but is a combination of n Root Key Component values, then the n shares are retrieved as R₁ . . . R_(n), and the value of R may be computed as follows: R=R ₁ ⊕R ₂ ⊕ . . . ⊕R _(n)

No other use may be made of any of the R₁ . . . R_(n) values, unless explicitly specified and approved.

Functional Key Provisioning is the process in which a Functional Key is inserted into the device. The entity that provisions a Functional Key of a particular Key Type is either Owner, or a Sub-owner who was delegated with authority to provision keys of that Key Type. Authority could have been delegated either from Owner or from another Sub-owner who is itself authorized to provision keys of the same Key Type, or of a more general Key Type Prefix. This section assumes that delegation has already been carried out, as specified in Section delegation.

To insert a Functional Key k of Key Type t, into the device, the following steps may be performed:

-   -   1. The provisioning entity carries out the following operations,         in the order specified:         -   (a) If the provisioning entity is a Sub-owner, then it finds             a proper chain of DELEGATION STRUCTURE objects, allowing it             to provision a key of type t. If the entity was delegated by             Owner, then such a chain is likely to have one DELEGATION             STRUCTURE element. If the entity was delegated by another             Sub-owner, then the chain will include DELEGATION STRUCTURE             objects chaining from Owner to the immediately delegating             Sub-owner, along with a final DELEGATION STRUCTURE object             delegating authority from that Sub-owner to the Sub-owner to             provision the key. The chain is always provided to the             provisioning entity in its entirety by the immediately             delegating Owner/Sub-owner—it is never constructed by the             provisioning entity. The selected chain shall be one in             which all ALLOWED TYPE SEGMENT fields of the DELEGATION             STRUCTURE objects, when concatenated with the DELIMITER             added between them, and with a DELIMITER added at the end,             form a prefix of t. For example, in some embodiments, a             chain of DELEGATION STRUCTURE objects with the following             respective ALLOWED TYPE SEGMENT fields: —System—, and             —Apps/DRM—, and —Scheme1—, are suitable for provisioning a             key where t=—System/Apps/DRM/Scheme1/PrKey—.         -   (b) It creates a BODY element containing ‘ADD’ in the             COMMAND field, and a KEY TYPE field, which holds the value             of t, after cutting off the Key Type Prefix generated by the             entire chain of DELEGATION STRUCTURE objects, if such exist.             (By the above example, the KEY TYPE field will contain             —PrKey—.)         -   (c) It uses its key, P, to compute both encryption and             integrity keys: K_(E) and K_(I), respectively. If the             provisioning entity is Owner, then P=R. Computation of these             keys shall be done as specified in Section body.         -   (d) It encrypts k with K_(E) using AES CCM.         -   (e) It appends E(K_(E),k), the value of KEY ID, t (as the             KEY TYPE), and a KEY SLOT value, to the BODY structure.         -   (f) It computes a MAC using K_(I) as the key, on the entire             BODY structure.         -   (g) It forms a PROVISIONING STRUCTURE from both the chain of             DELEGATION STRUCTURE objects and the BODY structure. The             resulting PROVISIONING STRUCTURE forms the Provisioning             Message.         -   (h) It may append to the Provisioning Message additional             PROVISIONING STRUCTURE objects in a similar manner. As an             implementation decision, it may be permissible to append             several BODY structures to the same PREAMBLE, if they all             suit the same Key Type Prefix (chain of DELEGATION STRUCTURE             objects).         -   (i) It communicates the Provisioning Message to the Key             Provisioning System on the device.     -   2. The client of the Key Provisioning System on the device         receives the Provisioning Message, and performs the following         operations:     -   3. It sets: C←R; A←Ø     -   4. It follows the chain of DELEGATION STRUCTURE objects in the         Preamble; for each such structure carrying out the following         actions:         -   (a) Parse the DELEGATION STRUCTURE object: the ALLOWED TYPE             SEGMENT into a, the TARGET KEY into t, and DELEGATION AUTH             into m.         -   (b) Compute K_(I) using C and the routine specified in             Section delegation-format.         -   (c) Compute a MAC on the DELEGATION STRUCTURE object.         -   (d) Compare the computed MAC with m. Terminate the process             immediately if MAC values do not match. Indication may             include the value of m where failure occurred.         -   (e) Compute K_(E) using C and the routine specified in             Section delegation-format.         -   (f) Set: C←D (K_(E), t)         -   (g) Set: A←A∥a∥ DELIMITER     -   5. It parses the BODY structure of the PROVISIONING STRUCTURE         object: the COMMAND, the KEY TYPE into t, the KEY SLOT into s,         the KEY VALUE into k, the KEY ID, and the Payload Auth into m.         The value of COMMAND is ADD, by the use-case definition.     -   6. It computes K_(I) using C and the routine specified above.     -   7. It computes a MAC using K_(I) and the fields of the BODY         structure.     -   8. It compares the computed MAC with m. It terminates the         process immediately if MAC values do not match. Indication may         include the fact that MAC of the BODY structure failed.     -   9. It computes: T←A∥t     -   10. It computes K_(E) using C and the routine specified above.     -   11. It computes D(K_(E),k) to obtain the key to be added.     -   12. It checks if a key is already stored with both the same Key         Type t and the same Key Slot s. It reports a suitable error if         one does, and terminates the process.     -   13. It files the decrypted key D(K_(E),k), along with the         computed Key Type T, Key Slot s, and the value of KEY ID.     -   14. It reports success.

The actions carried out by the provisioning entity and the Key Provisioning System on the device may be interlaced, so not to require the Key Provisioning System to store large chunks of data, such as the chains of Delegation Structure objects. For example, structures can be sent to the Key Provisioning System one by one, with the Key Provisioning System merely retaining a state throughout the process.

Enumeration and Removal of Keys: The process for the removal of keys resembles the process for addition of keys, with the following exceptions: (a) No KEY VALUE is provided in the BODY structure; (b) The key with the proper KEY TYPE and KEY SLOT is removed, if it exists.

The process for the enumeration of keys resembles the process for addition of keys, with the following differences: (a) No KEY VALUE is provided in the BODY structure. (b) The response from the Key Provisioning System may consist of the all type of KEY TYPE, KEY SLOT, and KEY ID, for those keys for which the KEY TYPE field starts with the value of T as computed above. In other words, the keys listed will be the ones of which the KEY TYPE field starts with T, which is conveyed by the combination of the BODY structure and the chain of DELEGATION STRUCTURE objects that were provided. (c) The KEY TYPE field of the BODY structure may be empty.

Turning to FIG. 1, there is shown a functional block diagram of a provisioning message preamble generator used by a target device root owner according to embodiments of the present invention. FIG. 2 is a functional block diagram of a provisioning message generator used by a first delegate according to embodiments of the present invention. FIG. 3 is a functional block diagram of a provisioning message preamble generator used by a first delegate to generate a message second portion to a preamble useable by a second delegate in accordance with embodiments of the present invention. FIG. 4 is a functional block diagram of a provisioning message generator used by a second delegate according to embodiments of the present invention. FIG. 5 is a functional block diagram of a target device including a cryptographic material provisioning module receiving a provisioning message in accordance to some embodiments of the present invention.

In accordance with some embodiments of the present invention, an electronic device may comprises: a cryptographic material provisioning (CMP) module to perform a method comprising: (a) receiving a CMP message which comprises a preamble and a payload; (b) decrypting the preamble of the CMP message by using a root key of the electronic device; (c) extracting from the decrypted preamble of the CMP message a first cryptographic key; (d) extracting from the decrypted preamble of the CMP message a primary permissions data vector indicating at least one of: (A) a type of keys that are authorized to be provisioned to the electronic device by a user of the preamble, and (B) an indication of whether or not the user of the preamble is authorized to delegate key provisioning rights to other entities; (e) decrypting at least a portion of the payload of the CMP message by using the first cryptographic key that was extracted from the preamble; (f) extracting a functional cryptographic key from the decrypted payload of the CMP message, wherein the extracted functional cryptographic key comprises a cryptographic key associated with at least one of: an application installed on the electronic device, and a process running on the electronic device; (g) checking key metadata, of the extracted functional cryptographic key, against one or more usage permissions indicated by the primary permissions data vector, and determining whether or not the extracted functional cryptographic key is of a type permitted for provisioning; (h) if it is determined that the extracted functional cryptographic key is of a type permitted for provisioning by the permissions data vector, then provisioning the extracted functional cryptographic key to said electronic device, wherein the provisioning comprises at least one of: (x) storing the extracted functional cryptographic key in the electronic device, (y) using the extracted functional cryptographic key in the electronic device, (z) installing the extracted functional cryptographic key in the electronic device; wherein the CMP message comprises a multi-level delegation hierarchy for provisioning one or more cryptographic keys for use by one or more applications of the electronic device; wherein the root key of the electronic device is used to delegate at least partial key provisioning rights to one or more other parties; wherein at least one of said other parties is authorized, based on a respective permissions data vector, to delegate at least part of the key provisioning rights to one or more other parties, wherein the electronic device is implemented by utilizing at least a hardware component.

In some embodiments, some or all of the preamble is digitally signed using the root key of the electronic device.

In some embodiments, said extracted functional cryptographic key is utilized by the electronic device for a process selected from the group consisting of (1) decrypting data, (2) encrypting data, (3) digital rights management, (4) signature generation, (5) signature verification, and (6) payment application.

In some embodiments, said CMP module is to regulate usage of the extracted functional cryptographic key by an application of the electronic device in accordance with usage permissions indicated by key metadata and by the primary permissions data vector.

In some embodiments, the method comprises: extracting from the decrypted payload of the CMP message a second cryptographic key usable for decrypting another portion of the CMP message.

In some embodiments, the decrypted payload of the CMP message further comprises a second permissions data vector; and said CMP module is to regulate usage of said second cryptographic key in accordance with usage limitations of both the first and second permissions data vectors.

In some embodiments, said CMP module is to process a portion of the CMP message using the second cryptographic key.

In some embodiments, said CMP module is to regulate usage of the extracted functional cryptographic key, extracted from said CMP message, in accordance with all usage limitations of all permissions data vectors within the CMP message.

In some embodiments, the primary permissions data vector defines one or more types of functional cryptographic key which may be included in the CMP message.

In some embodiments, said CMP module is not to process cryptographic material in the CMP message associated with functional keys of a type that is different from types defined in the primary permissions data vector.

In some embodiments, extracting the functional cryptographic key from the decrypted payload of the CMP message comprises: (A) determining that the decrypted payload comprises a secondary permissions data vector and a second cryptographic key; (B) extracting from the decrypted payload said secondary permissions data vector and said second cryptographic key; (C) regulating usage of the extracted functional cryptographic key in accordance with usage limitations of both the primary permissions data vector and the secondary permissions data vector.

In some embodiments, the CMP message comprises a two-part preamble and a payload portion; wherein the two-part preamble comprises: (A) a first preamble portion which stores (i) a first cryptographic key, encrypted by using the root key of the electronic device; and (ii) a first permissions vector associated with the first cryptographic key, wherein the first permissions vector defines provisioning limitations associated with the first cryptographic key; and (B) a second preamble portion which stores (iii) a second cryptographic key, encrypted by using the first cryptographic key; and (iv) a second permissions vector associated with the second cryptographic key, wherein the second permissions vector defines provisioning limitations associated with the second cryptographic key; wherein the payload portion comprises: (v) said functional cryptographic key, encrypted by using the second cryptographic key; wherein provisioning of the functional cryptographic key is regulated by provisioning limitations which correspond to an aggregation of the provisioning limitations of the first and second permission vectors.

In some embodiments, the multi-level delegation hierarchy has a non-predefined length.

In some embodiments, the CMP message comprises data for partial delegation functionality based on key types; wherein a member in a provisioning rights delegation hierarchy is authorized, by a respective permissions vector, to define which delegated key provisioning rights its delegates receive by delegation.

In some embodiments, the CMP message comprises data indicating that delegated key provisioning rights do not exceed key provisioning rights of a member higher in the a multi-level delegation hierarchy.

In some embodiments, the preamble of the CMP message is generated for a specific target device and is provided to a party intending to utilize the functional cryptographic key on said target device.

In some embodiments, the preamble of the CMP message: (A) is generated for a specific group of multiple target devices, and (B) is provided to a party intending to utilize the functional cryptographic key on said target device.

In some embodiments, the specific group of multiple target devices comprises at least one of: a group of multiple electronic devices that have a common maker; a group of multiple electronic devices that have a common model.

In some embodiments, a method of cryptographic material provisioning (CMP) may be implementable on an electronic device which comprises at least a hardware component; the method may comprise, for example: (a) receiving a CMP message which comprises a preamble and a payload; (b) decrypting the preamble of the CMP message by using a root key of the electronic device; (c) extracting from the decrypted preamble of the CMP message a first cryptographic key; (d) extracting from the decrypted preamble of the CMP message a primary permissions data vector indicating at least one of: (A) a type of keys that are authorized to be provisioned to the electronic device by a user of the preamble, and (B) an indication of whether or not the user of the preamble is authorized to delegate key provisioning rights to other entities; (e) decrypting at least a portion of the payload of the CMP message by using the first cryptographic key that was extracted from the preamble; (f) extracting a functional cryptographic key from the decrypted payload of the CMP message, wherein the extracted functional cryptographic key comprises a cryptographic key associated with at least one of: an application installed on the electronic device, and a process running on the electronic device; (g) checking the extracted functional cryptographic key against one or more usage permissions indicated by the primary permissions data vector, and determining whether or not the extracted functional cryptographic key is of a type permitted for provisioning; (h) if it is determined that the extracted functional cryptographic key is of a type permitted for provisioning by the permissions data vector, then provisioning the extracted functional cryptographic key to said electronic device, wherein the provisioning comprises at least one of: (x) storing the extracted functional cryptographic key in the electronic device, (y) using the extracted functional cryptographic key in the electronic device, (z) installing the extracted functional cryptographic key in the electronic device; wherein the method is implemented by an electronic device comprising at least a hardware component; wherein the CMP message comprises a multi-level delegation hierarchy for provisioning one or more cryptographic keys for use by one or more applications of the electronic device; wherein the root key of the electronic device is used to delegate at least partial key provisioning rights to one or more other parties; wherein at least one of said other parties is authorized, based on a respective permissions data vector, to delegate at least part of the key provisioning rights to one or more other parties.

Applicants have realized that a problem exists with regard to asset provisioning or cryptographic key provisioning, and that the problem may be common to many electronic devices that perform operations that should not be cloned by other devices. For cryptographic computations, to be such that can only be performed by a desired device, such device may be required to have access to data assets that are not available outside that device. Since the computation algorithm itself may not necessarily be confidential, the availability of such an asset is the only factor preventing a cloned, emulated, or otherwise undesired device, from performing an identical operation (e.g., fraudulently, by an attacker). In a demonstrative example, a Digital Rights Management (DRM) agent, such as a PlayReady client or a High-bandwidth Digital Content Protection (HDCP) receiver, may perform digital content decryption using key material that is presumably not available outside the device.

Applicants have realized that provisioning of protected assets (e.g., cryptographic keys), poses a challenge by being different from the other types of provisioning that a device is typically subject to, at least by three factors. First, the provisioned material should be provisioned securely, in a way that the confidentiality and/or the integrity of the provisioned material is protected. Second, the provisioned asset may be unique per device, or per a group (or batch) of devices, as opposed to typical software packages and images. Third, the provisioned asset may have monetary value associated with it, such that its acceptance by the device should be uniquely and positively indicated, and such indication may be used for billing purposes, licensing purposes, or other purposes having monetary consequences.

Applicants have developed a novel asset provisioning system, which may benefit multiple stakeholders, particularly in the field of Integrated Circuit (IC) manufacturers, device makers, service providers, and users.

A first stakeholder may be an IC Vendor (ICV), which may be a manufacturer of an IC of an electronic device where the system is deployed.

A second stakeholder may be an Original Equipment Manufacturer (OEM), which may obtain the IC from the ICV, and may assemble and ship the electronic device to end-users or to intermediary distributors (e.g., retailers, offline stores, online merchants).

A third stakeholder may be a Service Provider (SP), who may render service to end-users of the device, via the device. In some consumer electronic devices, the SP may provide services to managed devices which may be owned by the SP and may be managed by the SP; or the SP may provide services to non-managed devices, which may be owned and/or managed by a third party (e.g., the end-user itself, or an enterprise).

As demonstrated in the following use cases, some embodiments of the present invention may allow to maintain partial mistrust between stakeholders; and may allow secure provisioning of assets, as well as secure delegation of provisioning rights, even among parties that do not have complete trust among themselves, or among parties that may have partial mistrust among themselves.

In a first demonstrative use case, the present invention may enable secure provisioning of service keys. For example, the device may include an installed application, which may need to be provisioned with cryptographic material. The application is trusted to access the assets, using any suitable mechanism. The cryptographic material may be provided to each device individually, may be unique per device or per group of devices, and may facilitate the personalization of the secure application. The present invention may allow, for example, secure delivery of HDCP Rx key (HDCP Device Key) by the OEM or by the SP to deployed devices; secure delivery of Fast Identity Online (FIDO) Attestation key (a Class key) by the OEM or SP to deployed devices; secure delivery of PlayReady Model Key or PlayReady Device key by the content service provider to deployed devices; secure delivery of Wi-Fi Protected Access (WPA) key (a class Key), or other wireless communication cryptographic keys, by the SP or by other entity (e.g., an Information Technology (IT) department of an enterprise or organization) to deployed devices; or the like.

In a second demonstrative use case, the present invention may enable deferred personalization as a byproduct of the ability to provision service keys at any point over the device lifetime. For example, the present invention may allow to defer a licensing event, possibly along with its associated transaction, to a subsequent point in time at which the particular device actually requires the service.

In a third demonstrative use case, ad-hoc device assignment may be achieved. For example, parameters of the IC or of the device, may differ between instances that are shipped to different geographical regions or provided to different customers. This may require the provider (e.g., the ICV or the OEM) to configure its product before it is shipped, according to the destination of the shipment. This constraint may imply reduced flexibility in assigning and re-assigning products, as the products have to be tailored to their destination before leaving the premises of the provider. The provisioning mechanism of the present invention may allow the provider to provision configuration data at any time after the product leaves its premises, thereby allowing the provider to regain that flexibility.

In a fourth demonstrative use case, the present invention may allow flexibility in feature activation. For example, an ICV or OEM may sell different versions of the same product based on different sets of features that are enabled or disabled; with pricing determined accordingly. This may require that the parameters that indicate which features are enabled (or disabled) be provisioned to the device securely, and the present invention may enable such secure provisioning.

In a fifth demonstrative use case, the present invention may allow enforcement of manufacturing agreements. For example, the ability to “mark” and IC and devices may allow the IC vendor and/or the OEM to monitor the destiny of its designs, e.g., in terms of how many of them are manufactured and where they are sold. This may allow mitigating of “gray markets” (which are further discussed herein, in the following use case), as well the phenomenon of “third shifts”. Having a secure capability to tag products in the field, along with the ability to control the products based on this tag, allows the stakeholder to monitor and/or enforce what products operate in what region.

In a sixth demonstrative use case, the present invention may allow mitigation or elimination of “gray markets” for ICs or electronic devices. For example, an IC vendor or OEM may ship similar IC designs or similar devices, to different distribution regions, possibly by different distribution channels. The same product may be sold in different regions for different prices. There may often be an incentive to form “gray markets”, where an IC or a device is purchased for a low price at one region, and sold for a higher price in another region which is expected by the IC vendor or OEM to be served by another channel that sells the product for a higher price.

In a seventh demonstrative use case, the present invention may allow mitigation or elimination of “third shift” problems. An IC vendor may contract an external fabrication house, thereby having a risk that the manufacturer might in practice manufacture more ICs than reported, and sell them for its own gain. Similarly, an OEM may engage an external manufacturing or assembly factory (or an ODM, original design manufacturer), and may have a similar risk of the ODM manufacturing “clone” devices built on the OEM's design.

Some embodiments of the invention may be used for secure provisioning of various types of data items or digital items. Some embodiments may be utilized for secure provisioning of cryptographic assets, encryption keys, decryption keys, passwords, pass-phrases PINs, or the like. Some embodiments may be utilized for secure provisioning of non-cryptographic assets, or digital assets that may not necessarily include encryption keys and/or decryption keys. Some embodiments may be used for secure provisioning of both cryptographic assets and non-cryptographic assets. Some embodiments may be used for secure provisioning of licenses, playback licenses, software licenses, DRM licenses, multimedia licenses, activation code(s), software keys or product keys, serial numbers, unique identification numbers, or the like. In some embodiments, the terms “cryptographic asset” or “cryptographic key” may optionally include also such activation codes, licenses, playback licenses, software licenses, DRM licenses, multimedia licenses, software keys or product keys, serial numbers, unique identification numbers, digital files, or the like; as well as other suitable data items or data objects, for example, which may enable or disable or activate or deactivate one or more features or functionalities of an electronic device. Embodiments of the invention may be used in conjunction with secure provisioning of other suitable types of assets or data items.

Reference is made to FIG. 6, which is a schematic block diagram illustration of an electronic device 600 in accordance with the present invention. Device 600 may be or may comprise, for example, a smartphone, a cellular phone, a tablet, a phone-tablet (“Phablet”) device, a laptop computer, a notebook computer, a portable gaming device, a portable communication device, a portable wireless device, a portable computing device, a handheld device, a vehicular device, an Internet-connected device or appliance or environment, an “Internet of Things” (IoT) device or appliance or environment, a device connected to a “cloud” or to a “cloud computing” system or network, a Machine to Machine (M2M) system or environment, or other suitable electronic device.

Device 600 may comprise, for example, one or more Root of Trust (RoT) elements 611-614, as well as a secure storage 620. In a demonstrative example, RoT element 611-614 are depicted as located in device 600 outside of secure storage 620; however, in some embodiments, one or more, or all, of RoT elements 611-614 may be stored within secure storage 620. Device 600 may optionally comprise other hardware components and/or software modules that may often be included in an electronic device or computing device, for example, a processor, a central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), an input unit (e.g., a touch-screen, a keyboard, a physical keyboard, an on-screen keyboard, a keypad, a microphone, a stylus), an output unit (e.g., a screen, a touch-screen, audio speakers), a memory unit and/or storage unit (e.g., RAM unit(s), ROM unit(s), Flash memory, an SD-card, a SIM card, short-term memory units, long-term memory units, volatile memory, non-volatile memory), wireless transceiver(s) (e.g., Wi-Fi transceiver, cellular 4G transceiver, cellular 4G LTE transceiver, cellular 3G transceiver), antenna, Bluetooth component(s), GPS component(s), power source (e.g., rechargeable battery), an Operating System (OS), drivers, software applications, or the like.

ICV RoT 611 may be or may comprise an asymmetric master key, and may be used to identify ICs that are manufactured by the particular ICV. The private key may be composed of two key shares: a first key share which may be fixed in Register-Transfer Level (RTL); and a second, non-fixed key share which may be programmed into on-die One-Time-Programmable (OTP) memory during IC manufacture. Proper management of the non-fixed (e.g., OTP) key share may allow the ICV to use different keys for each batch of ICs. If these batches also correspond to warehousing or distribution granularity, then the ICs used by different OEMs may have different root keys, thereby allowing to protect the ICV's supply chain. ICV RoT 611 may be the primary secret RoT that is also known outside of device 600.

This master key is used to derive two private keys: k_(ICV,E) used for encryption and k_(ICV,A) used for authentication; and one symmetric association key k_(a). The corresponding public keys are K_(ICV,E) and K_(ICV,A). The public keys are certified by the IC Vendor by signing them with an ICV server private key k_(s) and storing the certificate C_(ICV) on the device: C _(ICV) =S[k _(S) ,K _(ICV,A) ∥K _(ICV,E)]

Accordingly, other parties may validate the keys during protocol execution using an ICV server public key, K_(s). To create the signature, the IC Vendor deploys a hardware security module (HSM) that holds k_(s) and the RTL share: given the OTP share, the HSM calculates k_(ICV,A) and k_(ICV,E) and generates C_(ICV) (the OTP share may be also generated and outputted by the same HSM). The symmetric association key k_(a) is used by IC Vendor for provisioning the same way as other Provisioning Servers use their own association keys (note that all such keys are denoted k_(a)).

In some embodiments, all Provisioning Servers hold implicitly trusted copies of all k_(s) values that pertain to devices with which they communicate.

Some of the protocols described herein may utilize Ik_(a), the identity of k_(a), to select a specific association key. Ik_(a) has a special value to denote the k_(a) used by IC Vendor for provisioning; otherwise Ik_(a) consists of the identity of the Provisioning Server I_(PRS), and the type of the association key (“personalized” or “class-wide”). The identity of the Provisioning Server I_(PRS) may be calculated as a hash of K_(PRS,E) and K_(PRS,A), as follows: I _(PRS) =H[K _(PRS,E) ∥K _(PRS,A)])

Device Local RoT 613 is a symmetric master key, which may be utilized for secure storage on device 600, as well as for deriving session keys. Device Local RoT 613 is generated within device 600 by device 600 itself, and is not available externally to device 600.

Authorization RoT 614 is a public authorization key, which may be used to verify the eligibility or identities of communicating entities. These identities may serve a back-end component or sub-system which may be responsible for billing and/or reporting. Therefore, Authorization RoT 614 need not be trusted by the provisioning and delegation mechanisms, and a compromise of Authorization RoT 614 does not pose a threat to provisioned assets and/or to the delegation mechanism. Authorization RoT 614 may be hard-coded, and may be functionally equivalent in all devices that utilize the mechanisms of the present invention. The private key that is the counterpart of the public key of Authorization RoT 614 is available only in an authorization server, or in back-end components or sub-systems associated with such authorization server.

Some embodiments may optionally use an OEM RoT 612, which may be an asymmetric master key able to identify devices that are manufactured by a specific OEM, based on a specific IC. The private key of OEM RoT 612 may be derived from ICV RoT 611 and the OEM's code-signing public key. OEM RoT 612 may be generally equivalent in its functional purpose to the ICV RoT 611; but OEM RoT 612 may be further specific for the OEM. The OEM RoT 612 may be specific for a combination of an OEM and the public key used to verify the boot image. In some implementations, the OEM RoT 612 may be known only to the ICV, and may not be known to the particular OEM (or to other OEMs or third parties). For example, the particular OEM may use a delegation mechanism (e.g., as described herein) to be introduced with another key that may be used by the OEM for provisioning on behalf of the OEM.

In accordance with the present invention, two main embodiments are described herein. A first novel embodiment (denoted as “Embodiment AA”) enables secure provisioning of cryptographic assets. A second novel embodiment (denoted as “Embodiment BB”) enables secure provisioning of cryptographic assets while providing enhanced security against side-channel attacks. A function or operation or step, that is common to both of these embodiments, is denoted as being associated with “Embodiment AA/BB”.

The present invention may utilize suitable cryptographic algorithm(s). For example, some implementations may utilize 128-bit security, symmetric keys and Elliptic Curve Cryptography (ECC) public keys over NIST P-256 curve. For derivation of keys from symmetric master keys, the system may utilize a key derivation function such as, for example, “KDF in Counter Mode” of NIST Special Publication 800-108, “Recommendation for Key Derivation Using Pseudorandom Functions”, with AES-CMAC as the pseudorandom function (in Embodiment AA), or with HMAC (SHA-256) as the pseudorandom function (in Embodiment BB). For symmetric operations, some implementations may utilize 128-bit AES; for example, utilizing CBC mode for encryption, utilizing CMAC mode for authentication, and utilizing CCM mode for authenticated encryption. Cryptographic hashing may be performed with SHA-256. For asymmetric operations, some implementations may utilize ECDSA and ECIES. In all communications and storage, ECC public keys are stored in uncompressed format.

In Embodiment BB, authenticated encryption E [k,m] is performed by using AES-CCM. In embodiment BB, if the message identifier is given, then it is concatenated with the message: E[k,i,m]=E[k,i∥m]

In accordance with the present invention, E [k,m] denotes symmetric authenticated encryption of message m using secret key k. The secret key k may be a concatenation of two keys: k=k₁∥k₂.

The present invention may limit, mitigate or reduce the power consumption information leakage when using a cipher, ensuring sure that an attacker cannot cause the system to operate with the same (secret) key on different input values.

The SCA tolerance protocols may prevent the same key from being used with more than one input, or with a few inputs. All changes are made to make sure that this feature is retained, even against an attacker who controls the inputs.

In order to achieve tolerance or protection against a side-channel attack (SCA) or side-channel leakage, the authenticated encryption E [k,m] is performed in accordance with the following four-step method.

The first step comprises generating a series of random blocks r, having a total size identical to the size as the message. The generating may be performed, for example, by utilizing “Hash_DBRG” (as described in NIST Special Publication 800-90A, “Recommendation for Random Number Generation Using Deterministic Random Bit Generators”, National Institute of Standards and Technology (NIST), which is hereby incorporated by reference in its entirety), instantiated with entropy input k₁ (128 bits) and a random nonce n (64 bits) (e.g., a pseudo-random nonce that is utilized during instantiation of the Hash_DRBG function; and not requiring a different nonce for each generate), so that each 256-bit output block is generated separately (the update is done after generating every block) up to an aggregate size that equals the size of the message. In some implementations, the generate function of Hash_DRBG utilizes a parameter which indicates how many pseudo-random bits to produce; this function produces the requested number of pseudo-random bits, and updates the state; in a demonstrative implementation of the present invention, instead of calling the Hash_DRBG function once with the entire message-size the parameter, the system calls the Hash_DRBG function multiple times, each time utilizing the number 256 as the parameter; thereby forcing the Hash_DRBG function to update the state after every generated block of pseudo-random bits.

The second step comprises performing a XOR operation of the message m with the series of random blocks r, to provide confidentiality. It is noted that the XOR operation is described as a demonstrative implementation; and other suitable operations or steps may be performed, such as, applying other functions that ensure checksum integrity.

The third step comprises authenticating the result: n∥m⊕r with HMAC using k₂ (128 bits) as the key, to provide integrity.

The fourth step may comprise, for example, generating as output: the nonce n, and m⊕r, and also H[k₂, n∥m⊕r].

With regard to the above-mentioned steps, it is further noted as follows: In some conventional systems, a message is broken into chunks (blocks) and then encrypted one block at a time; such that the same encryption key is used repetitively throughout the message (once per each block). In contrast, the present invention encrypts a long message using a single key in the above-mentioned four-step manner, which form an authenticated encryption scheme; namely, an encryption scheme that protects both confidentiality and integrity of the input.

In order to limit or prevent side-channel leakage or SCA, the method should not be used twice with the same key; namely, the method may be re-used by utilizing different keys. For example, a message-specific key ki may be generated or derived by using two different approaches based on the size of the message identifier i.

A demonstrative implementation may utilize deriving of keys from a master key. For example, if the system needs to utilize a different key each time, then the system may derive all those keys from one master key, as this is what the system may have available (one, single, master key). The derivation function is a derivation function that shall not re-use the master key in the derivation process, because that would imply using the same key (master key, in this case) with multiple inputs. Accordingly, keys are derived using a pseudo-random number generator (PRNG) mechanism or module or unit, or by using a hash function, e.g., depending on how many keys are needed.

The above-mentioned four-step method utilizes, or may be implemented, by having two keys: a first key (K1) for confidentiality, and a second key (K2) for integrity. For example, key K1 is used to create a stream of pseudo-random bits of any length by utilizing key K1 only once. The input is then XOR'ed with this stream. The second key K2 is utilized with HMAC to compute a hash that is used to assure integrity.

In the first approach, the message identifier i may be a relatively small integer, such that 0≤i<N, where N may be a pre-defined positive integer (for example, N may be equal to 50 or 100 or 500 or 900, or other suitable values), then DRBG may be used to generate all N message keys while using i as an index in this array: k_(i)=P [k]_(i) (where every k_(i) consists of two 128-bit keys, and thus occupies 256 bits); such that: E[k,i,m]=E[P[k∥Short]_(i) ,m]

In the above, “Short” may indicate a literal or a fixed pre-defined string of characters; such as, the string “SHORT”. In the first approach, the sender may not assure uniqueness of i by generating it at random, and thus the sender has to track and maintain a record or a log indicating which i values were already used (in order to avoid their re-use). In some implementations, the message identifiers may be consecutive; and thus, instead of keeping and updating an entire array, it may be possible to store only the latest (most-recent) DRBG state and a small set of unused previous keys (e.g., 5 or 20 or 60 unused previous keys). For example, the Device received messages having message identifiers of 1, 2, 3 and 6; and thus, the Device has to generate keys 1, 2, 3, 4, 5 and 6, while keeping track that keys 4 and 5 are not yet used.

If the number of deriving keys (N) is relatively small (for example, up to 100 or 500 or 900 keys), then the system may be able to afford the time to have up to N operations to recover a key; and the system may thus utilize the PRNG for each key derivation. However, since the PRNG always generates all keys (up to the one needed) in succession, obtaining key number 900 would require to generate 899 keys that are discarded before getting to the 900th key that will be retained and used.

With regard to impact on synchronization, it is further noted: Some implementations may benefit from the ability to derive keys in succession without re-using the master key more than once; however, when both parties (server and client) communicate, they need to “remember” (or monitor, keep track, log) which derived keys they have already used in order to avoid re-using the same derived key twice. If the key sample space is small, then choosing a key identifier at random may not be sufficiently safe or secure, as repetitions may occur. Instead, the client device needs to either “remember” (store, keep track of) all derived keys that it had used in the past and refuse to use (or discard without using) a derived key that had already been used; or the client device may synchronize with the server in order to use the derived keys sequentially, in which case it may suffice for the client device to only “remember” (store, keep, log) the last or most-recent derived key that was used, realizing that all derived keys before it are “burnt” and may not be re-used, while all the subsequent derived keys following it are approved for utilization. Similarly, the server shall also “remember” (store, track, log) what the last used key is. Such implementation may require additional interactions between the client device and the server for synchronization of the most-recent derived key that was used.

In the second approach, the message identifier i may be a relatively large integer (for example, i≥N); and a key derivation function is used to derive k_(i) from the long-term key k (namely, the key k is used more than once; a non-ephemeral key) and from the message identifier i: k _(i) =R[k,Long,i]

If the number of keys is large, to the extent that the system cannot afford (or does not desire to allocate) the time and/or the processing power for deriving a key (e.g., particularly when the processing time and/or processing power that are required, are generally proportional to the number of possible keys), then the system may utilize a “random access” access to keys, by using a hash to create the key directly from the master key. In such case, no synchronization of “most-recent key used” is needed between the client device and the server. However, the client device should still “remember” (store, keep track, log) all derived keys that were used so far, to ensure that the client device is not led or elicited to re-use a previously-used derived key.

In some implementations, the first approach is utilized by the system for authenticated encryption of a Provisioning message, which is considered a high-security message; whereas, the second approach is utilized by the system for authenticated encryption of a Querying message, which is considered a medium-security message.

In some implementations, the first approach is utilized by the system for authenticated encryption of a Provisioning message, which is considered a high-security message; whereas, the second approach is utilized by the system for authenticated encryption of any other message except for a Provisioning message.

The following notations may be used for cryptographic operations:

E [K,m] denotes encryption of message m using public key K;

E [k,m] denotes symmetric authenticated encryption of message m using session key k (namely, an ephemeral secret key);

E [k,i,m] denotes symmetric authenticated encryption of message m, wherein the session key is derived from the long-term key k and the message identifier i (which may also be referred to as “session identifier”);

H [m] denotes cryptographic hash of message m;

H [k,m] denotes HMAC of message m with secret key k;

P [s] denotes output of DRBG utilizing seed material s (each output block is generated separately);

R [k,l,c] denotes key derivation function which utilizes key k, label l, and context c;

S [k,m] denotes signature of message m using private key k.

A Provisioning Server certificate includes the server's signing public key (also used as an identifier for this server), its encryption public key, and flags assigned by the Authorization Server; the certificate is signed by private key matching the Authorization RoT. The flags may indicate, for example, whether this server has to present an authorization ticket with delegation records and with regular asset provisioning records. Some implementations of the system need not manage a namespace of Provisioning Servers.

Asset Provisioning is a main feature provided by the system. The provisioning protocol may need to satisfy all the relevant security requirements, for example: providing assets only to the correct devices, ensuring asset confidentiality and integrity, and ensuring closure with the billing systems. The provisioning protocol may assure that the server initiating the provisioning transaction is an authorized Provisioning Server.

In some implementations, one or more prerequisites should be met before asset provisioning may be performed, for example: enrollment, key availability, and identification.

With regard to enrollment, before an asset owner can provision an asset to the device using a Provisioning Server, the Provisioning Server must obtain from the Authorization Server a Provisioning Server certificate for the public keys of the Provisioning server, namely, for public keys K_(PRS,E) and K_(PRS,A). This procedure ensures that devices are only approached by authorized servers, and that the billing cycle can be properly updated or closed.

Additionally, the Provisioning Server has to be properly delegated by a Provisioning Server located higher in the hierarchy, referred to as the Delegation Server. This delegation is expressed in a “delegation record” which had to be created in the device before asset provisioning can take place. The creation of such delegation record is accomplished using the delegation protocol as detailed herein.

With regard to an Association Key as a prerequisite for provisioning, before an asset owner can provision an asset to the device using a Provisioning Server, the Provisioning Server that is about to perform provisioning must have an association key k_(a) derived from the ICV root-of-trust. This may be achieved by utilizing one of two demonstrative methods.

In a first demonstrative method, if the Provisioning Server is a provisioning server of the IC Vendor, then the Provisioning Server will use the IC Vendor association key k_(a) derived directly from the ICV root-of-trust.

In a second demonstrative method, any other entity or asset owner, that runs or implements a Provisioning Server, needs to have a delegation record in the secure storage of the device. The delegation record contains the symmetric association key k_(a) to be used by this Provisioning Server for this device (for personalized provisioning, or device-specific provisioning) or for this device class (for class-based provisioning, to a class or group or batch of devices that belong to the same class or type). The delegation record is created by utilizing a suitable Delegation Protocol, as described herein.

In Embodiment AA, the association key k_(a) may be a single 128-bit key for authenticated encryption.

In Embodiment BB, each association key k_(a) may be a concatenation of three keys: k _(a) =k _(a) ^(p) ∥k _(a) ^(q) ∥k _(a) ^(d)

In the above, k_(a) ^(p) is used for authenticated encryption of provisioning messages; k_(a) ^(q) is used for authenticated encryption of the query messages; and k_(a) ^(d) is an HMAC key used for an additional protection of the provisioning message (e.g., to prevent or mitigate Denial of Service (DoS) attacks).

Some embodiments of the present invention may protect against (or may prevent or mitigate) DoS attacks or “flooding”, by using an outer wrap.

Applicants have realized that regardless of whether message indexes are short (and are used in succession) or if message indexes are long (and are derived directly), the Device needs to store all index values that were used, to ensure that the Device does not process a message that has an index value that was already processed. If a message is processed using the same index number, it implies that the same derived keys are used twice; and this may be risky, even if the message ends up being rejected. Therefore, the Device first checks that it has never seen the index number before; and then processes the message; and then records that this new index has been utilized and thus should not be re-used.

Applicants have realized that this mechanism may create a venue for attacks. For example, an attacker may “flood” the Device with many fake (or unauthorized, illegitimate, fraudulent) messages. Indeed, the fake messages will be detected, and the device will not respond to them, but the mere detection of a fake message requires using the key and thus “burning” the index number, as well as recording the “burnt” index number. In some implementations, storage on the Device may be scarce or may be limited, and thus the attacker may use this flow to bombard the device with fake messages and cause the device to run out of storage to store (e.g., “forever”) all the index values that the Device has encountered.

The present invention may provide a solution to this problem that the Applicants have identified. For example, the Device may perform a pre-processing stage, in which the integrity of the message is checked using a simpler non-tolerant keyed cryptographic checksum (such as HMAC), using a different key which is not necessarily protected against side channel attacks.

In some embodiments, the protection mechanism may comprise the following steps. Firstly, the Device receives a message. The message has the checksum of authenticated encryption using a one-time protected key. In addition, the entire protected message is wrapped with an “outer integrity protecting layer”, which results in an additional integrity signature appended to the message, using a different, non-one-time, “outer wrapping key”. For example, an external HMAC using an HMAC key.

Secondly, the Device checks the outer HMAC (or other integrity mechanism) against the “outer wrapping key” that the Device has (e.g., stored within the Device) for that provisioning server; by utilizing the third key, namely, the outer wrapping key. If the check fails, then the Device halts the process and does not check the body (and/or the payload) of the message using a one-time key; thereby avoiding a “burning” (a utilization) of an index number, and avoiding the need to store internally within the Device such “burnt” (used) index number. In contrast, if (and only if) the outer signature is verified by the Device by using the outer wrapping key, then the Device proceeds with the process of using (“burning”) a key, checking the message, storing an indication that the key (or index) where used.

The system protects the internal indexes and their resulting one-time keys; while also risking (to a certain degree) the outer wrapping key, which is one key that is frequently used. However, this process is still secure, even if revealed by an SCA operator or attacker; because it only allows the attacker to mount a flooding DoS attack on the Device that uses this particular “outer wrapping key”, and not against other devices. Since an SCA necessarily requires physical access to the Device (or, at least, extreme physical proximity to the Device being attacked), then the SCA becomes a non-efficient route of attack; because an attacker that already has physical access to the Device, and would like to “deny service” from the Device, may more easily disable the device by breaking the device or by stealing it, rather than by applying a cumbersome SCA process.

With regard to identification, the provisioning may be carried out using a one-pass protocol. This protocol assumes that the Device and Provisioning Server share a symmetric association key k_(a). The Device has the value of k_(a) either derived from the ICV root-of-trust, or from a delegation record pertaining to the Provisioning Server in question. If the value of k_(a) is not yet available to the Provisioning Server, then an identification protocol (or other suitable discovery protocol) may be performed prior to the one-pass provisioning protocol.

For example, the following Identification Protocol may be used: Provisioning Server→Device: I _(k) _(a) Provisioning Server←Device: E[K _(PRS,E) ,k _(a) ∥M∥C _(ICV) ∥S[k _(ICV,A) ;I _(k) _(a) ∥k _(a) ∥M]]

Protocol 1: Identification Protocol

The Provisioning Server initiates the protocol by communicating or sending to the Device the Ik_(a), which is the identity of the symmetric association key k_(a) to retrieve. In this protocol, Ik_(a) cannot have the special value denoting the symmetric association key k_(a) used by the IC Vendor for provisioning, since that symmetric association key k_(a) has no delegation record.

If the Device is not provisioned (delegated) to communicate using such an association key, then the device replies with a “nonsense” message indistinguishable from a correct response. Otherwise, the Device has the delegation record corresponding to I_(PRS). In this case Device retrieves the association key k_(a) and fixed metadata M corresponding to Ik_(a); the Device signs Ik_(a) and k_(a) and M using k_(ICV,A) (for example, in order to prevent or mitigate side-channel attacks, the signature is calculated during the delegation and is stored in the database); and the Device sends the association key k_(a) and the metadata M together with the certificate C_(ICV) and the signature, all encrypted with the public key of the Provisioning Server, K_(PRS,E). The Provisioning Server uses its private key k_(PRS,E) to decrypt the message, validates the certificate C_(ICV), and stores the association key k_(a).

Upon completion of the above: (A) the Provisioning Server is aware of the symmetric association key k_(a) to be used with the particular Device; (B) the Provisioning Server is ascertained that a genuine device has sent this association key k_(a) to be used with the particular Provisioning Server, through the signature of the Device using k_(ICV,A); and (C) an outside observer or listener or attacker cannot deduce the value of the association key k_(a), and cannot deduce the identity of the Device.

The system may utilize a one-pass provisioning protocol.

For example, Embodiment AA may utilize the following one-pass provisioning protocol: Provisioning Server→Device: I _(k) _(a) ,E[k _(a) ,I _(M) ,M]

Protocol 2AA: One-Pass Provisioning Protocol

For example, Embodiment BB may utilize the following one-pass provisioning protocol: Provisioning Server→Device: I _(k) _(a) ,m=I _(M) ∥E[k _(a) ^(p) ,I _(M) ,M],H[k _(a) ^(d) ,m]

Protocol 2BB: One-Pass Provisioning Protocol

In Embodiment AA, the Provisioning Server sends to the Device: the Ik_(a), which is the identity of the symmetric association key k_(a) to use; and the message identifier I_(M) to prevent replay attack; and a message M encrypted with the symmetric association key k_(a).

In Embodiment BB, the Provisioning Server sends to the Device: (1) the Ik_(a), which is the identity of the symmetric association key k_(a) to use; and (2) the message identifier I_(M) to prevent replay attack and/or to diversify the encryption key (namely, to diversify the provisioning component k_(a) ^(p) that is utilized to encrypt the message M by the Provisioning Server); and (3) a message M encrypted with an encryption key derived from the provisioning component k_(a) ^(p) of the selected symmetric association key k_(a) and the short message identifier I_(M); and (4) an HMAC of items (2) and (3) calculated by utilizing the anti-DoS component k_(a) ^(d) (an outer wrapping sub-key) of the symmetric association key k_(a).

The symmetric association key k_(a) was obtained by the Provisioning Server either during the identification stage (personalized device-specific provisioning), or was known due to the fact that all devices in a class share the same association key (class-based provisioning).

The encrypted message M may include: (1) an identifier of the type of message (a provisioning message); (2) the asset id IA; (3) the asset payload A; (4) other metadata.

The association key k_(a) being used for the Provisioning Server is taken from a delegation record corresponding to I_(PRS). For example, if a message with the same I_(PRS)∥I_(M) was already processed by the Device, then the message is considered a duplicate and the message processing is stopped or aborted (e.g., prior to, and without, an attempt to decrypt the message M); otherwise, the HMAC tag is checked. If the HMAC tag is correct, then the message identifier is saved, and authenticated decryption of the message M is performed by utilizing the component or sub-key k_(a) ^(p). If the decryption succeeds, then the Device also verifies that this Delegation Record permits the processing of this type of asset. If the Delegation Record does not permits the processing of this type of asset, then the processing is aborted; otherwise, the processing is performed.

If the asset is a hardware feature-activation value, Provisioning Server sends the asset's activation address and the model-identifier for which this asset is valid, as part of I_(A). Then, the Device verifies compatibility using the model-identifier and access permissions for the activation address.

If the asset id suggests that the provisioned asset is a duplicate of an existing asset, then its value is replaced (e.g., in accordance with the Replacement method as described herein).

The delegation process allows a Provisioning Server which acts as a Delegation Server to introduce a new Provisioning Server. This is the basis for the hierarchical nature of the provisioning scheme. In a delegation process, the delegating Provisioning Server (which may be referred to as “Delegation Server”) generates a delegation message including key material of a new Provisioning Server, and provisioning policy. The delegation message may then be provisioned to device(s), enabling the delegated Provisioning Server to perform its own provisioning (or delegation) processes thereafter. The delegation message is provisioned similarly to regular assets, using the authorized one-pass delegation protocol. After execution of the protocol, the Device stores a delegation record corresponding to this Provisioning Server.

For delegation to be performed, the Delegation Server has to be able to provision the device. Therefore, the enrollment and key availability prerequisites stated above need to be met by the Delegation Server. The Delegation Server also has to be authorized for delegation by another Delegation Server which delegated its rights for provisioning, if indeed it was itself delegated by such other Delegation Server. Additionally, for the Provisioning Server (target of delegation) to submit the delegation structure to the Device, the enrollment requirement needs to be met by that Provisioning Server.

The delegation may be performed by using the provisioning protocol, except that the asset provisioned, A, is of a special type, a delegation message. The delegation message may comprise: (1) the public key of the delegated Provisioning Server (needed for execution of the identification protocol); (2) encrypted association key (needed for class provisioning); and (3) the provisioning policy to be applied on the delegated Provisioning Server. At least one of those two keys is required; but both options can be present to allow a single Provisioning Server to use both personalized (device-specific) provisioning and also class-based (or class-wide) provisioning.

For demonstrative purposes, the delegation process may be described herein as if Delegation Server communicates with the Device prior to any communication between the Device and the delegated Provisioning Server. However, it is possible for the delegated Provisioning Server to act as an intermediary in this communication between the Delegation Server and the Device, and thus allow the Provisioning Server to get provisioning rights for a given device while communicating with that Device.

To delegate provisioning rights to Provisioning Server, the Delegation Server receives from Provisioning Server, through an out-of-band secure channel: (1) the public encryption key K_(PRS,E) of the Provisioning Server, certified by Authorization Server (e.g., in a Provisioning Server certificate) to allow delegation by the Delegation Server; and (2) optionally, in class-based or class-wide provisioning, the class association key k_(a) encrypted using K_(ICV,E), namely, E[K_(ICV,E), k_(a)], where the public key K_(ICV,E) is a part of the device certificate C_(ICV), which can be made available, e.g. using the identification protocol; and (3) the signature on the above message using k_(PRS,A), namely, the signature:

The Provisioning Server receives the device certificate C_(ICV) from the Delegation Server; which may get it, for example, using the identification protocol. Before extracting the public key K_(ICV,E), the Provisioning Server validates the device certificate C_(ICV) by using K_(s), which is the ICV server key for authentication (e.g., a key stored on a server that is owned or operated or controlled by the IC Vendor) and which may be obtained through an out-of-band secure channel.

Using the provisioning process, Delegation Server sends this information to Device, together with the policy for provisioning (the Delegation Server specifies what assets the Provisioning Server is authorized to provision) as an asset A and the metadata associated with the asset. The asset id in this case may be I_(PRS), namely, the identity of the Provisioning Server. If class-wide or class-based provisioning is not utilized, the Provisioning Server need not generate, encrypt and send the class association key k_(a) and the associated signature; and thus, the Provisioning Server need not receive or validate the device certificate C_(ICV).

The Device then checks or verifies: (1) that the Delegation Server has rights for delegation (e.g., the Device may perform this autonomously, since the Device stores a database of delegation records, which is updated using the Delegation Protocol); and (2) that the following cryptographic hash holds true, I _(PRS) =H[K _(PRS,E) ∥K _(PRS,A)]

The device further checks or verifies: (3) that the certificate on K_(PRS,E) and K_(PRS,A), in association with the Delegation Server, is valid. Furthermore, if the class-wide association key k_(a) is present (e.g., if the flag or other indication is set to indicate class-wide or class-based provisioning), then the device further checks or verifies: (4) that the signature on E [K_(ICV,E), k_(a)] is valid (and the class-based or class-wide association key k_(a) can be decrypted).

If the above-mentioned verifications hold true, then the Device prepares the delegation record. For example, if the flag or other indication for class-wide provisioning is set, the Device uses k_(ICV,E) to decrypt the class-wide association key k_(a). If the flag or other indication for personalized (device-specific) provisioning is set, then the device randomly generates the personalized association key k_(a). The Device then stores in the secure storage the delegation record that is indexed by I_(PRS) and contains policy, K_(PRS,E), and the one or two association keys k_(a).

Asset management may include common operations on assets, other than provisioning: querying, modification and removal, being carried out using the system by a Provisioning Server.

With regard to Querying, a Provisioning Server that knows an association key of a Device (e.g., the association key k_(a) was obtained by the Provisioning Server, either during an Identification stage utilizing the Identification Protocol, or was known due to the fact that all devices in a class share the same class association key k_(a)), may query the Device using a querying protocol.

For example, Embodiment AA may utilize the following demonstrative querying protocol: Provisioning Server→Device: I _(k) _(a) ,E[k _(a) ,I _(M) ,Q] Provisioning Server←Device: E[k _(a) ,I _(M) ,R]

Protocol 3AA: Querying Protocol

For example, Embodiment BB may utilize the following demonstrative querying protocol: Provisioning Server→Device: I _(k) _(a) ,I _(M) ,E[k _(a) ^(q) ,I _(M) ,Q] Provisioning Server←Device: E[k _(a) ^(q) ,I _(M) ,R]

Protocol 3BB: Querying Protocol

In accordance with Querying Protocol 3AA, the Provisioning Server sends to the Device: (1) the Ik_(a), which is the identity of the symmetric association key to use; and (2) the long message identifier I_(M); and (3) the query Q encrypted using the association key k_(a). If the Device has the specified association key k_(a), then Device calculates a response R (the response may also be an error message), and sends it back encrypted with the association key k_(a); otherwise the Device produces and sends back a message that is indistinguishable (without knowing the association key k_(a)) from a valid message.

In accordance with Querying Protocol 3BB, the Provisioning Server sends to the Device: (1) the Ik_(a), which is the identity of the symmetric association key to use; and (2) the long message identifier I_(M); and (3) the query Q encrypted using a key derived from the querying part k_(a) ^(q) of the selected association key k_(a). If the Device has the specified association key k_(a), then Device calculates a response R (the response may also be an error message), and sends it back encrypted with the key derived from k_(a) ^(q) and the long message identifier I_(M); otherwise the Device produces and sends back a message that is indistinguishable (without knowing the association key k_(a)) from a valid message.

In some embodiments, the message identity for query messages is not saved by the Device, for example, if a lower degree of tolerance against side-channel leakage is required. In such cases, key derivation with long message identifier is used, and the protection against DoS attacks may be omitted.

In accordance with the present invention, asset modification may be implemented by re-provisioning. Upon provisioning of an asset with an asset id which is already being used, the new asset is appended to the secure storage, and the sectors holding the old copy are marked as “deleted”.

In accordance with the present invention, asset removal may be performed by provisioning an asset with a null payload and a deletion flag. The asset id of the null asset corresponds to the asset that shall be removed. Upon reception of the null asset, the secure storage marks the area where the asset is stored as “deleted”.

Assets are provisioned into the device so they may be used or consumed by components or modules on the device. In a demonstrative implementation, assets are consumed only by being read; and the reading of values of assets may be moderated or controlled by utilizing a permissions mechanism.

In the asset obtainment processes, the contents of assets are provided to subjects in response to an API call. In regular cases, the API call may return the actual asset. For feature activation assets, the system may provide the asset value directly to the relevant hardware module, and the API call may only indicate success or failure.

In order to make use of a provisioned asset, an application running on the Secure OS or on the HLOS should invoke an interface that is provided as part of the system. This interface is provided within the Secure OS, to be used by secure application(s). Additional, an HLOS driver may provide to HLOS application(s) access to this interface.

A calling application that attempts to use the API is required to provide the asset id identifying the sought asset. In return, the system returns the payload of the required asset (unless the asset is a feature activation that was directly pushed to the hardware). On failure, the API returns a code that indicates one of the following error conditions: (1) “Not found”, indicating that there is no asset in the secure storage that carries the specified asset id; (2) “Unauthorized”, indicating that the credentials provided are not sufficient to grant access to the asset; (3) “Failure”, indicating that another failure occurred, such as when checking the integrity of the secure storage, which prevents the asset from being made available.

Each asset metadata contains a permission field which indicates what entities are permitted to access the asset. A permissions module on the device may control the access to each such asset, in accordance with the value indicated in the permission field.

In a demonstrative implementation, the system may not support multiple permission levels. Specifically, it provides entities on the device with read access only. Assets may be read, but cannot be modified or even deleted by on-device consumers. Asset deletion is supported only through the provisioning mechanism itself, i.e., with the help of an authorized Provisioning Server.

In a demonstrative implementation, the system need not support security token functionality, which restricts access to cryptographic services that utilize the asset, rather than provide the value of the asset directly. When a subject is authorized on an asset, this authorization implies the right to obtain a copy of the asset at runtime. Such token access is advised when assets are to be used by untrusted code. This functionality may be implemented by separate TEE code.

The permission field may support the following subjects: “All”, “TEE”, “Specific-TEE”, and “Specific-HLOS”.

The subject “ALL” indicates all code on the device. The asset will be freely available to any application, either running on the TEE (Trusted Execution Environment) or running on the HLOS (High Level Operating System) (through a suitable driver) that runs on the device.

The subject “TEE” indicates all TEE code on the device. The asset will be available to all functions running in the TEE of the device.

The subject “Specific-TEE” indicates a specific TEE function. The asset will be available to one or more positively identified TEE functions on the device. The Secure OS is responsible for determining and reporting the caller identity to the code implementing the invention for this restriction to be enforced.

The subject “Specific-HLOS” indicates a specific HLOS function. The asset will be available to one or more positively identified HLOS applications on the device. The HLOS application may identify itself using a challenge-response protocol, where the secret value required for responding to the challenges is embedded in an HLOS shared library. This HLOS shared library may use data obfuscation techniques to protect the challenge-response secret and shall verify the calling application's identity using code integrity verification.

Some embodiments may enable Ticketing and authorized provisioning. For example, in some implementations, a Provisioning Server operator may be required to acquire an authorization ticket from the Authorization Server in order to provision assets. In such cases, the Provisioning Server certificate issued to this Provisioning Server will include a flag indicating that this Provisioning Server must present a valid authorization ticket with provisioning events.

A Provisioning Server required to present an authorization ticket must first obtain such tickets issued for its assets. In order to perform this ticket issuance, the Provisioning Server may contact the Authorization Server and present its own Provisioning Server certificate and a hash digest computed over an asset. The Authorization Server may log the transaction (for subsequent billing purposes), and may issue an authorization ticket containing a signature on the asset hash. The signature is computed using a ticket signing key which is signed by the Authorization RoT. The ticket will then be verified by receiving devices as a condition to their storing this asset.

In order to authorize delegation records, the Delegation Server may send the public key of the delegated server (not its hash) to the Authorization Server. The Authorization Server may issue an authorization ticket by signing this public key.

In order to minimize the number of ticketing transactions, the system may issue a single authorization ticket covering multiple assets. For example, the Provisioning Server may build a Merkle tree containing all the assets as leaves, and request a ticket for the tree's top hash. The ticket request, and the resulting ticket, should indicate the tree size, which should be a power of 2. When the Provisioning Server then presents the ticket to the Device, it will also present a minimal subset of the nodes to permit the device to reconstruct the Merkle tree and verify that the top hash matches that stated in the ticket.

Reference is made to FIGS. 7A-7E, which are schematic block-diagram illustrations of a system 700 and its components, in accordance with some demonstrative embodiments of the present invention. FIG. 7A shows a demonstrative implementation of system 700, which may comprise: an authorization server 701, provisioning servers 731-733, and electronic devices 771-772. Components of system 700 may be able to communicate with each other, directly and/or indirectly, via one or more wired and/or wireless communication links, via Local Area Network (LAN), via Wide Area Network (WAN), via TCP/IP or Internet connection(s), or the like.

It is noted that the units or components of FIGS. 7A-7E may comprise other suitable modules or sub-units, in order to perform or implement one or more of the operations or functionalities or protocols described herein. For example, an Identification Module may perform the operations associated with Identification; an Enrollment Module may perform the operations associated with Enrollment; a Provisioning Module may perform the operations associated with Provisioning; a Delegation Module may perform the operations associated with Delegation; a Querying Module may perform the operations associated with Querying; and so forth. Such modules may be server-side, may be client-side or device-side, or may be implemented on a provisioning server and/or delegation server and/or the authorization server and/or the electronic device(s).

Provisioning server 731 may provision asset(s) to device 771.

Provisioning server 732 may have right(s) to provision asset(s) to device 772. Provisioning server 732 may operate as a Delegation Server; and may delegate some or all of its provisioning rights to “target” or “delegated” provisioning server 733. The delegated provisioning server 733, in turn, may provision asset(s) to device 772, in strict accordance with the provisioning right(s) as previously delegated by Delegation Server 732 to delegated Provisioning Server 733.

In accordance with the present invention, Delegation Server 732 may not reveal the asset(s) that were actually provisioned by the delegated Provisioning Server 733 to device 772; even if Delegation Server 732 has access to all the communications that take place within system 700.

In accordance with the present invention, Delegation Server 732 may operate as an “introducing” server, and may “introduce” the delegated Provisioning Server 733 to device 772. Upon such “introduction” (or, delegation of provisioning rights), the delegated Provisioning Server 733 may send an encrypted asset (X) to device 772; and the Delegation Server 732 is not capable of deciphering or decrypting the encrypted asset (X), even though the Delegation Server 732 was the entity that “introduced” the delegated Provisioning Server 733 to device 772 in the first place, and even though the Delegation Server 732 may be able to listen on all the communications among components of system 700.

FIG. 7B is a more detailed block-diagram illustration of a demonstrative implementation of Authorization Server 701.

FIG. 7C is a block-diagram illustration of a demonstrative implementation of Provisioning Server 731.

FIG. 7D is a block-diagram illustration of a demonstrative implementation of Delegation Server 732.

FIG. 7E is a block-diagram illustration of a demonstrative implementation of device 772.

Each one of the units shown in FIG. 7A may comprise, for example: a processor 751 able to execute code or programs or applications; a memory unit 752; a storage unit 753; a wired or wireless communication unit 754 (e.g., transmitter, receiver, transceiver, Network Interface Card (NIC), modem, or the like); a key generator 755 able to generate keys, symmetric keys, asymmetric keys, private keys, public keys, encryption keys, decryption keys, key-pair(s), or the like; a Random Number Generator (RNG) 756 able to generate random or pseudo-random numbers which may be used by other sub-units or modules (e.g., by key generator 755); an encryption unit 757 or encryption module; a decryption unit 758 of decryption module; a signing unit 759 or signing module; a signature verification unit 760 or signature verification module; and other suitable hardware components and/or software modules.

It is noted that for demonstrative purposes, and in order to not obscure the invention with excessive amount of components and unique numerals, the various units or modules that are mentioned in this paragraph are shown in FIGS. 7A-7E as having repeating numerals, even though each of them may be implemented differently across different units of system 700; for example, the processor is shown as processor 751 all across FIGS. 7B-7E, even though the Authorization Server 701 may comprise a first type of processor, the Provisioning Server 731 may comprise a second (different) type of processor, device 772 may comprise a third (different) type of processor, and so forth.

Turning to FIG. 7B, the Authorization Server 701 may further comprise, for example: an authorization module 711; a single-asset pre-authorization ticket generator 712; and a multiple-asset pre-authorization ticket generator 713.

Turning to FIG. 7C, the Provisioning Server 731 may further comprise, for example: a feature activation module 781; an enrollment module 784; a server-side module 785 able to perform one or more operations as a provisioning server towards the device(s), or other operations or functionalities described herein in relation to the server side; a one-pass provisioning server-side module 786; a delegation record acquisition module 787; a query message generator 789; a pre-authorization ticket obtainer 792; and a Merkel Tree builder 793.

Turning to FIG. 7D, the Delegation Server 732 may comprise components 799 which may include some or all of the components of Provisioning Server 731; and may further comprise, for example: a delegation record generator 742; a delegation-server-side module 743; and a pre-authorization ticket obtainer 744.

Turning to FIG. 7E, device 772 may further comprise, for example: a Secure Storage 721; a Trusted Execution Environment (TEE) 722; a Secure Operating System (Secure OS) 723; a High-Level Operating System (HLOS) 724; one or more Root of Trust (RoT) elements 725; one or more delegation record(s) 726; a device-side module 729 able to implement or perform one or more of the functionalities described herein in relation to device-side operations; a one-pass provisioning device-side module 745; a delegation record processing module 746; a device-side personalization module 747; a query response message generator 748; an asset modification module 749; an asset removal module 705; an asset obtainment module 706; an asset consumption module 707; a Permission Field enforcing module 708; and a Merkle Tree reconstructor 709.

It is clarified that the term “a key-generation scheme that utilizes a deterministic random number generation function” (or similar terms), as used herein, may comprise: a key-generation scheme that actually utilizes a deterministic random number generation function; and/or, a key-generation scheme that is capable of utilizing a deterministic random number generation function (e.g., even if such key-generation scheme does not actually utilizes the deterministic random number generation function, for the purposes of a particular implementation or operation, and/or does not actually generate pseudo-random numbers).

It is clarified that the term “a key-generation scheme that utilizes a hash-based non-deterministic random number generation function” (or similar terms), as used herein, may comprise: a key-generation scheme that actually utilizes a hash-based non-deterministic random number generation function; and/or, a key-generation scheme that is capable of utilizing a hash-based non-deterministic random number generation function (e.g., even if such key-generation scheme does not actually utilizes the hash-based non-deterministic random number generation function, for the purposes of a particular implementation or operation, and/or does not actually generate pseudo-random numbers).

Portions of the discussion herein may describe, for demonstrative purposes, secure and/or controlled provisioning of cryptographic assets (e.g., encryption key, decryption key, cryptographic key, password, Personal Identification Number (PIN), pass-phrase); however, the present invention may be utilized for, or in conjunction with, secure and/or controlled provisioning of other types of assets, for example, non-cryptographic assets, licenses, activation codes, Digital Rights Management (DRM) items or DRM-related items, or the like.

In some embodiments, a method of cryptographic material provisioning (CMP) may comprise: (a) generating a delegation message at a first provisioning server, wherein the delegation message indicates provisioning rights that are delegated by the first provisioning server to a second provisioning server with regard to subsequent provisioning of cryptographic assets to an electronic device; wherein generating the delegation message comprises at least one of: (A) inserting into the delegation message an association key unknown to the first provisioning server, encrypted using a public key of said electronic device, wherein said public key of said electronic device is usable to encrypt data for subsequent decrypting by said electronic device using said private encryption key of said electronic device; and/or (B) inserting into the delegation message a public key of the second provisioning server; enabling the electronic device to locally generate said association key unknown to the first provisioning server; wherein the association key is retrievable by the second provisioning server based on the public key of the second provisioning server; (b) delivering the delegation message from the first provisioning server to the electronic device; (c) at the second provisioning server, and based on said delegation message, provisioning one or more cryptographic assets to the electronic device, using said association key.

In some embodiments, the first provisioning server, by listening to all communications among the first provisioning server, the second provisioning server, the electronic device, and an authorization server, cannot decipher the contents of one or more cryptographic assets that are provisioned by the second provisioning server to the electronic device, even though said first provisioning server delegated to said second provisioning server one or more provisioning rights to subsequently provision one or more of said cryptographic assets.

In some embodiments, the first provisioning server, which introduced the second provisioning server to the electronic device for purposes of subsequent provisioning of cryptographic assets, cannot decipher data exchanged between the second provisioning server and the electronic device, even though the second provisioning server and the electronic device did not have any shared secrets and did not have any cryptographic key data usable for secure communication between the second provisioning server and the electronic device prior to said introduction by said first provisioning server.

In some embodiments, the method may comprise: delegating from the first provisioning sever to the second provisioning server, a right to securely send a cryptographic asset from the second provisioning server to the electronic device, wherein the first provisioning server cannot decipher any cryptographic asset that is sent from the second provisioning server to the electronic device.

In some embodiments, wherein generating the delegation message comprises: inserting into the delegation message a public key of the second provisioning server, to enable execution of an identification protocol for subsequent personalized provisioning of a cryptographic asset to said electronic device.

In some embodiments, generating the delegation message comprises: inserting into the delegation message an association key to be used with the second provisioning server, to enable subsequent execution of provisioning of a cryptographic asset to one or more electronic devices using said association key.

In some embodiments, delivering the delegation message to the electronic device is performed via a one-pass one-way communication from the first provisioning server to said electronic device.

In some embodiments, the method may comprise, prior to performing step (a): securely delivering from the second provisioning server to the first provisioning server, via a secure communication channel, (A) a public encryption key of the second provisioning server, and (B) a class-wide association key encrypted with a key that allows the association key to be decrypted by said electronic device.

In some embodiments, the method may comprise: provisioning from the first provisioning server to the electronic device, via a one-pass one-way provisioning protocol, at least: (i) the public encryption key of the second provisioning server, (ii) the server certificate of the second provisioning server, digitally signed by an authorization server; (iii) an indication of which cryptographic assets the second provisioning server is authorized to subsequently provision to the electronic device.

In some embodiments, generating the delegation message comprises: inserting into the delegation message one or more flags indicating to the electronic device whether the second provisioning server is authorized to provision: (X) only personalized cryptographic assets, or (Y) only class-wide cryptographic assets for a class of multiple electronic device, or (Z) both personalized and class-wide cryptographic assets.

In some embodiments, the method may comprise: prior to provisioning a particular cryptographic asset from the second provisioning server to the electronic device, performing: acquiring by the second provisioning server an authorization ticket, from an authorization server, indicating that the second provisioning server is authorized to provision the particular cryptographic asset to said electronic device.

In some embodiments, said acquiring of the authorization ticket is triggered by a flag, indicating that authorization is required for each provisioning event performed by the second provisioning server, the flag located in a server certificate issued by said authorization server to the second provisioning server.

In some embodiments, the acquiring comprises: at the second provisioning server, contacting the authorization server to present to the authorization server (A) a server certificate of the second provisioning server, and (B) a hash of the particular cryptographic asset intended to be provisioned by the second provisioning server to the electronic device.

In some embodiments, the acquiring further comprises: receiving at the second provisioning server, from said authorization server, said authorization ticket which comprises a digital signature by the authorization server on the hash of the particular cryptographic asset intended to be provisioned by the second provisioning server to the electronic device; wherein said digital signature enables said electronic device to verify by the electronic device prior to storing said particular cryptographic asset.

In some embodiments, provisioning the cryptographic asset to the electronic device is performed via a one-pass one-way communication from the second provisioning server to said electronic device.

In some embodiments, a system for cryptographic material provisioning (CMP) may comprise: a first provisioning server to generate a delegation message, wherein the delegation message indicates provisioning rights that are delegated by the first provisioning server to a second provisioning server with regard to subsequent provisioning of cryptographic assets to an electronic device, wherein the first provisioning server is to generate the delegation message by performing at least one of: (A) inserting into the delegation message an association key unknown to the first provisioning server, encrypted using a public key of said electronic device, wherein said public key of said electronic device is usable to encrypt data for subsequent decrypting by said electronic device using said private encryption key of said electronic device, and/or (B) inserting into the delegation message a public key of the second provisioning server; enabling the electronic device to locally generate said association key unknown to the first provisioning server; wherein the association key is retrievable by the second provisioning server based on the public key of the second provisioning server; wherein the first provisioning server is to cause delivery of the delegation message from the first provisioning server to the electronic device; wherein the second provisioning server is to provision, and based on said delegation message, one or more cryptographic assets to the electronic device, using said association key.

In some embodiments, a method of performing cryptographic material provisioning (CMP) may comprise: (a) generating a delegation message at a first provisioning server, wherein the delegation message indicates provisioning rights that are delegated by the first provisioning server to a second provisioning server with regard to subsequent provisioning of cryptographic assets to an electronic device; wherein generating the delegation message comprises: inserting into the delegation message an association key unknown to the first provisioning server, encrypted using a public key of said electronic device, wherein said public key of said electronic device is usable to encrypt data for subsequent decrypting by said electronic device using said private encryption key of said electronic device; wherein the step of inserting said association key into the delegation message comprises: generating an association key that is a concatenation of a first sub-key, a second sub-key, and a third sub-key that is an outer wrapping key; wherein the method further comprises: utilizing the first sub-key for authenticated encryption of a provisioning message intended for sending to said electronic device; utilizing the second sub-key for authenticated encryption of a non-provisioning query message intended for sending to said electronic device; utilizing the third sub-key for preliminary authentication of the integrity of the delegation message; (b) delivering the delegation message from the first provisioning server to the electronic device; (c) at the second provisioning server, and based on said delegation message, provisioning one or more cryptographic assets to the electronic device, using said association key.

The association key (with its three parts or components or sub-keys) is not necessarily generated by the second server; but rather, in some implementations, it may be generated by the device itself. For example, there may be two modes of operation. In a first mode, as described above, the second server generates the association key (e.g., and the second server sends the association key to the device; or alternatively, the sending of the association key to the device may be performed by the first server, by utilizing data that originated from the second server), and the device decrypts the association key; for example, in class-based or class-wide provisioning. In a second mode (e.g., device-specific provisioning, customized provisioning, personalized provisioning), the device generates or “makes up” a random or pseudo-random association key (with its three parts or components or sub-keys), and the device sends the association key that it generated to the second server as part of the identification protocol.

In some embodiments of the present invention, the system may utilize the following keys, or some of them.

A first key is an Association Key, comprising three parts or components or sub-keys, (I) for Confidentiality, (II) for Authenticity, and (III) for denial-of-service prevention; the Association Key is one for each device-server pair, and never changes. In some embodiments, the Association Key may be a fixed, non-changing, shared secret key between a Server and a Recipient Device; or between a pair of server-device; known only to that pair of server and device, and not known to other devices, and not known to other servers or other entities which are not associated with the server.

A second key is a Secret Encryption Key, used to encrypt each message; different for each message; derived from sub-key (I) above, for each message separately, using either deterministic random number generator or key-generator, based on the Confidentiality sub-key and based on a unique message-specific identifier of the message intended for encryption (e.g., a natural number, which may be a running index number, but in some implementations may be a non-consecutive natural number that is non-index number and non-consecutive to any other message identifier. In some implementations, when protecting a query message, then a key generator function is used; whereas, when protecting a provisioning message, then a deterministic random number generator is used.

A third key is a Secret Authentication Key, used to protect the integrity of each message. In some implementation, the Secret Authentication Key is equal to sub-key (II) mentioned above, for a particular message or for all messages exchanged between a particular server-device pair.

A fourth key is an Outer Wrapping Key, which is component of sub-key (III) mentioned above.

In some embodiments, each message is encrypted using a generator for key-stream, using the Secret Encryption Key for that message; and has an integrity checksum computed by using the Secret Encryption Key (component (II) mentioned above); and has an outer wrapping by using component (III) mentioned above.

Some embodiments may comprise a method of authenticated encryption of one or more messages, the method comprising: (a) storing, at least temporarily, a message intended for authenticated encryption; wherein the message has an arbitrary message-length; (b) storing, at least temporarily, a secret authentication key and a secret encryption key; (c) generating a key-stream set of blocks, each block consisting of pseudo-random bits; wherein an aggregate length of said key-stream set of blocks is equal to or greater than said message-length of said message; wherein each block of said key-stream set of blocks is generated by executing a deterministic pseudo-random number generator function that is instantiated with the secret encryption key as entropy input; wherein said key-stream set of blocks is generated on a block-by-block basis until said key-stream set of blocks reaches in aggregate said message-length of said message; wherein said key-stream set of blocks is generated on a block-by-block basis without re-using at any one block, in conjunction with said deterministic pseudo-random number generator function, any key that was utilized at any other block for said deterministic pseudo-random number generator function; (d) encrypting on a per-block basis, each block of bits of said message, with a corresponding block from said key-stream set of blocks; (e) authenticating at least one of: (A) the result of said encrypting operation, or (B) said message, by applying a keyed cryptographic checksum function that ascertains integrity and that utilizes said secret authentication key; (f) generating as output at least: (i) the result of said encrypting operation of step (d), and (ii) the output of said keyed cryptographic checksum function of step (e).

In some embodiments, the method may comprise: performing authenticated encryption of multiple messages, in a manner that reduces utilization of any single secret encryption key, by executing the steps (a) through (f) separately for each message of said multiple messages; wherein the authenticated encryption of each message of said multiple messages is processed in steps (a) through (f) by utilizing a unique secret encryption key that is unique only to the authenticated encryption of said message; wherein each unique secret encryption key is utilized only for authenticated encryption of a single message of said multiple messages, and is not utilized for authenticated encryption of any other message of said multiple messages.

In some embodiments, said secret authentication key is utilized as common authentication key for authentication of each message of said multiple messages.

In some embodiments, said message is part of a set of messages intended for authenticated encryption, wherein each message is associated with a unique message-specific identifier; wherein said message is intended for communication from a server to a recipient device; wherein the secret encryption key, that is used for the authenticated encryption of said message, is generated by utilizing a key-generation scheme that takes into account: (i) said unique message-specific identifier of said message, and (ii) at least a component of an association key that associates between said server and said recipient device, wherein the association key is a shared secret key that is known to said server and said recipient device.

In some embodiments, said secret encryption key, that is used for the authenticated encryption of said message, is generated by utilizing a particular key-generation scheme; wherein said message comprises a provisioning message that is utilized by a provisioning server to provision a digital asset to a recipient device; wherein the method comprises: applying as said particular key-generation scheme, for the authenticated encryption of said message, a key-generation scheme that utilizes as input: (i) output from a deterministic pseudo-random number generation function, and (ii) a unique identifier of said message.

In some embodiments, said secret encryption key, that is used for the authenticated encryption of said message, is generated by utilizing a particular key-generation scheme; wherein said message comprises a provisioning message that is utilized by a provisioning server to provision a digital asset to a recipient device; wherein the method comprises: applying as said particular key-generation scheme, for the authenticated encryption of said message, a key-generation scheme that utilizes as input: (i) output from a deterministic pseudo-random number generation function, and (ii) a unique identifier of said message; at said recipient device, upon receipt of an encrypted message, and prior to attempting to perform cryptographic verification and cryptographic decryption of a payload of said encrypted message, performing: verifying that an index number of said encrypted message was not yet used by said recipient device for cryptographic verification or cryptographic decryption of any other message received by said recipient device.

In some embodiments, said secret encryption key, that is used for the authenticated encryption of said message, is generated by utilizing a particular key-generation scheme; wherein said message comprises a query message; wherein the method comprises: applying as said particular key-generation scheme, for the authenticated encryption of said message, a key-generation function that derives said secret encryption key from at least a message-specific identifier of said message.

In some embodiments, said secret encryption key, that is used for the authenticated encryption of said message, is generated by utilizing a particular key-generation scheme; wherein said message comprises a query message; wherein the method comprises: applying as said particular key-generation scheme, for the authenticated encryption of said message, a key-generation function that derives said secret encryption key from at least: (i) a unique message-specific identifier associated with said message, and (ii) a component of an association key that associates between a provisioning server and a recipient device, wherein the association key is a shared secret key that is known to said server and said recipient device.

In some embodiments, said secret encryption key, that is used for the authenticated encryption of said message, is generated by utilizing a particular key-generation scheme; wherein if said message comprises a provisioning message that is utilized by a provisioning server to provision a digital asset to a recipient device, then the method comprises: applying as said particular key-generation scheme, for the authenticated encryption of said message, a key-generation scheme that utilizes a deterministic pseudo-random number generation function; wherein if said message comprises a query message, then the method comprises: applying as said particular key-generation scheme, for the authenticated encryption of said message, a key-generation function that derives said secret encryption key from at least: (i) a unique message-specific identifier associated with said message, and (ii) a component of an association key that associates between a provisioning server and a recipient device, wherein the association key is a shared secret key that is known to said server and said recipient device.

In some embodiments, said secret encryption key, that is used for the authenticated encryption of said message, is generated by utilizing a particular key-generation scheme; wherein if said message is part of a group-of-messages having less than N messages, wherein N is a pre-defined natural number, then the method comprises: applying as said particular key-generation scheme, for the authenticated encryption of said message, a key-generation scheme that utilizes a deterministic pseudo-random number generation function; wherein if said message is part of a group-of-messages having at least N messages, then the method comprises: applying as said particular key-generation scheme, for the authenticated encryption of said message, a key-generation function that derives a key from: (i) a message-specific identifier of said message, and (ii) a component of an association key that associates between a provisioning server and a recipient device, wherein the association key is a shared secret key that is known to said server and said recipient device.

In some embodiments, the authenticating of step (e) comprises: applying a keyed-hash message authentication code that uses said secret authentication key.

In some embodiments, the authenticating of step (e) comprises: applying a keyed block cipher authentication code that uses said secret authentication key.

In some embodiments, the method comprises: performing authenticated encryption of multiple messages, in a manner that reduces utilization of any single confidentiality key, by executing the steps (a) through (f) separately for each message of said multiple messages; wherein the authenticated encryption of each message of said multiple messages is processed in steps (a) through (f) by utilizing a unique secret encryption key that is unique only to the authenticated encryption of, at most, said message and one additional message; wherein each unique secret encryption key is utilized only for authenticated encryption of up to two messages of said multiple messages, and is not utilized for authenticated encryption of any other message of said multiple messages except for said up to two messages.

In some embodiments, the method may comprise: performing authenticated encryption of multiple messages, in a manner that reduces utilization of any single confidentiality key, by executing the steps (a) through (f) separately for each message of said multiple messages; wherein the authenticated encryption of each message of said multiple messages is processed in steps (a) through (f) by utilizing a unique secret encryption key that is unique only to the authenticated encryption of, at most, said message and K additional messages, wherein K is a natural number; wherein each unique secret encryption key is utilized only for authenticated encryption of up to K+1 messages of said multiple messages, and is not utilized for authenticated encryption of any other message of said multiple messages except for said up to K+1 messages.

In some embodiments, the method may comprise: reducing side-channel leakage from a cryptographic unit that decrypts multiple discrete messages, by performing said steps (a) through (f) of authenticated encryption, separately, on each one of said multiple discrete messages; wherein said cryptographic unit avoids utilizing the same encryption key twice for authenticated encryption of more than one message of said multiple discrete messages.

In some embodiments, said message is part of a set of messages intended for authenticated encryption; wherein said message is associated with a unique index number; wherein the secret encryption key, that is used for the authenticated encryption of said message, is generated by utilizing a key-generation scheme that takes into account said unique index number of said message.

In some embodiments, a method may comprise: (a) receiving at an electronic device an encrypted message that comprises: (i) a payload encrypted with a secret one-time key; and (ii) an outer integrity protection layer comprising a keyed cryptographic checksum generated by utilizing a secret key; (b) checking the keyed cryptographic checksum of the outer integrity protection layer of the message, against a key that is securely stored within said electronic device; (c) if the checking result is negative, then: (i) aborting decryption of the payload of said message, and (ii) aborting cryptographic verification of said message; and (iii) avoiding utilization of a secret one-time key generated by said electronic device for decrypting said payload; (d) if the checking result is positive, then: utilizing a one-time key generated by said electronic device, for decrypting said payload.

In some embodiments, in step (c), the method further comprises: if the checking result is negative, then: aborting any further cryptographic processing of said message.

In some embodiments, in step (d), the method further comprises: if the checking result is positive, then: recording within a storage of said electronic device, an indication that said one-time key is discarded and cannot be re-used for subsequent cryptographic operations by said electronic device.

In some embodiments, the receiving of step (a) comprises: receiving at the electronic device an encrypted message that comprises: (i) a payload encrypted with a secret one-time key; and (ii) an outer integrity protection layer comprising a keyed cryptographic checksum generated by utilizing a secret non-one-time key; wherein the checking of step (b) comprises: checking the keyed cryptographic checksum of the outer integrity protection layer of the message, against a non-one-time key that is generated by said electronic device.

Discussions utilizing terms such as “processing”, “computing”, “calculating”, “determining”, or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities within the computing system's registers and/or memories into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices.

Embodiments of the present invention may include apparatuses for performing the operations herein. This apparatus may be specially constructed for the desired purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs) electrically programmable read-only memories (EPROMs), electrically erasable and programmable read only memories (EEPROMs), magnetic or optical cards, or any other type of media suitable for storing electronic instructions, and capable of being coupled to a computer system bus.

The term “cryptographic operation” as used herein may include, for example, encoding, decoding, signing, authenticating, hashing, and/or performing other suitable operations related to cryptography and/or data security. For example, a “cryptographic operations module” or a “crypto-token module” may include an encoding module and/or a decoding module and/or other suitable modules or units.

The term “random” as used herein, may further comprise “pseudo-random”. The term “pseudo-random” as used herein, may further comprise “random”. The terms “random” and “pseudo-random”, as used herein, may comprise: having randomness; lacking pattern; lacking predictability; unpredictable; lacking order; not following an intelligible pattern; not following a predictable pattern or order. Portions of the discussion herein that relate to a “generator” of random or pseudo-random bits or numbers or values, or to a “function” or “module” that utilizes (as input and/or as output) random or pseudo-random numbers or values or bits, may thus include the generation and/or utilization of such “random” and/or “pseudo-random” numbers, values or bits.

Some embodiments may be implemented by using a suitable combination of hardware components and/or software modules, which may include, for example: a processor, a central processing unit (CPU), a digital signal processor (DSP), a single-core or multiple-core processor, a processing core, an Integrated Circuit (IC), a logic unit, a controller, buffers, accumulators, registers, memory units, storage units, input units (e.g., keyboard, keypad, touch-screen, stylus, physical buttons, microphone, on-screen interface), output units (e.g., screen, touch-screen, display unit, speakers, earphones), wired and/or wireless transceivers, wired and/or wireless communication links or networks (e.g., in accordance with IEEE 802.11 and/or IEEE 802.16 and/or other communication standards or protocols), network elements (e.g., network interface card (NIC), network adapter, modem, router, hub, switch), power source, Operating System (OS), drivers, applications, and/or other suitable components.

Some embodiments may be implemented as an article or storage article (e.g., CD or DVD or “cloud”-based remote storage), which may store code or instructions or programs that, when executed by a computer or computing device or machine, cause such machine to perform a method in accordance with the invention.

Some embodiments may be implemented by using a software application or “app” or a “widget” which may be downloaded or purchased or obtained from a website or from an application store (or “app store” or an online marketplace).

Functions, operations, components and/or features described herein with reference to one or more embodiments of the present invention, may be combined with, or may be utilized in combination with, one or more other functions, operations, components and/or features described herein with reference to one or more other embodiments of the present invention.

While certain features of the present invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents may occur to those skilled in the art. Accordingly, the claims are intended to cover all such modifications, substitutions, changes, and equivalents. 

What is claimed is:
 1. A method comprising: (a) receiving at an electronic device an encrypted message that comprises: (i) a payload encrypted with a secret one-time key; and (ii) an outer integrity protection layer comprising a keyed cryptographic checksum generated by utilizing a secret key; wherein said encrypted message is part of a group of encrypted messages that are intended for decryption; wherein said encrypted message has a message-identifier; wherein a secret cryptographic key is stored only in (I) said electronic device and in (II) an authorized server apparatus which sends said encrypted message to said electronic device; wherein said secret cryptographic key comprises at least three concatenated sub-keys; wherein a first sub-key of said secret cryptographic key is utilized by said authorized server for authenticated encryption of provisioning-messages that provision digital assets to said electronic device, wherein a second sub-key of said secret cryptographic key is utilized by said authorized server for authenticated encryption of query-messages that query said electronic device, wherein the third sub-key of said secret cryptographic key is utilized by said electronic device as an outer integrity protection layer to verify integrity of an encrypted message received at said electronic device without firstly decrypting the payload of said message; (b) checking the keyed cryptographic checksum of the outer integrity protection layer of the message, against said third sub-key that is securely stored within said electronic device; (c) if the checking result is negative, then: (i) aborting decryption of the payload of said message, and (ii) aborting cryptographic verification of said message; and (iii) avoiding utilization of a secret one-time key generated by said electronic device for decrypting said payload; (d) if the checking result is positive, then: utilizing a one-time key generated by said electronic device, for decrypting said payload; wherein the method comprises: protecting said recipient device from incoming fake messages, by checking at the recipient device, prior to attempting to decrypt a particular message, that an index number of said particular message is not a same index number of any other message that was received for decryption at said recipient device.
 2. The method of claim 1, wherein in step (c), the method further comprises: if the checking result is negative, then: aborting any further cryptographic processing of said message.
 3. The method of claim 1, wherein in step (d), the method further comprises: if the checking result is positive, then: recording within a storage of said electronic device, an indication that said one-time key is discarded and cannot be re-used for subsequent cryptographic operations by said electronic device.
 4. The method of claim 1, wherein the receiving of step (a) comprises: receiving at the electronic device an encrypted message that comprises: (i) a payload encrypted with a secret one-time key; and (ii) an outer integrity protection layer comprising a keyed cryptographic checksum generated by utilizing a secret non-one-time key; wherein the checking of step (b) comprises: checking the keyed cryptographic checksum of the outer integrity protection layer of the message, against a non-one-time key that is generated by said electronic device. 